questions regarding nsswitch and the internal-sftp server and ChrootDirectory options

Ben H bhendin at gmail.com
Thu Aug 14 11:20:48 EST 2014


What is the intended behavior of the internal-sftp server when looking
to resolve identity information for user via the nsswitch configured
mechanisms?
I am seeing different behavior between two packaged versions and am
looking to understand what should be expected.

Scenario:

Utilizing a developed directory services plugin (dsplug), "ls" access
on the sftp session fails with the following on a RHEL 6.5 machine
with OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013:

CONSOLE OUTPUT:
---------------
sftp localjoe at localhost
Connecting to localhost...
Password:
sftp> ls
Connection closed

LOG OUTPUT:
-----------
tail /var/log/secure
Aug 13 19:27:17 centos65-01 sshd[6203]: Accepted
keyboard-interactive/pam for localjoe from ::1 port 38958 ssh2
Aug 13 19:27:17 centos65-01 sshd[6203]: pam_unix(sshd:session):
session opened for user localjoe by (uid=0)
Aug 13 19:27:17 centos65-01 sshd[6208]: subsystem request for sftp
Aug 13 19:27:19 centos65-01 sshd[6209]: error: select: Bad file descriptor
Aug 13 19:27:19 centos65-01 sshd[6208]: Received disconnect from ::1:
11: disconnected by user
Aug 13 19:27:19 centos65-01 sshd[6203]: pam_unix(sshd:session):
session closed for user localjoe

STRACE OUTPUT:

-------------

lstat("/sftptest", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/etc/localtime", 0x7fff2c118340)  = -1 ENOENT (No such file or directory)
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
close(4)                                = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 4
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR)               = 0
connect(4, {sa_family=AF_FILE, path="/opt/dsplug/sockets/.auth"}, 110)
= -1 ENOENT (No such file or directory)
close(4)                                = 0
open("/etc/group", O_RDONLY|O_CLOEXEC)  = -1 ENOENT (No such file or directory)
...
select(5, [3], [4], NULL, NULL)         = -1 EBADF (Bad file descriptor)


I am able to get around these issues with the following in nsswitch.conf:

passwd:     files [UNAVAIL=return] nis dsplug

shadow:     files nis

group:      files [UNAVAIL=return] nis dsplug

This however has the negative effect of not resolving any UID/GID
information within the sftp session.

On a Kubentu 13.11 machine with OpenSSH_6.2p2 Ubuntu-6ubuntu0.1,
OpenSSL 1.0.1e 11 Feb 2013, this issue does not occur in a default
configuration.
An strace on that system shows that no calls past passwd/group files
are made and no attempt seems to be done to resolve any naming
information (including local passwd/group)

Should internal-sftp make any attempt past local passwd/group files?
It appears at least in the RHEL testing if only "files nis" is
configured that NIS names will be properly resolved... ?

thank you


More information about the openssh-unix-dev mailing list