internal-sftp stuck on 'ls' with chrootdirectory

[Brian Rosenberger]

Hi all,

I am using Match directive and internal-sftp to chroot sftp users into their
directory. Connection and login works. I can change directories and put/get
files. Also logging of the internal sftp-process works (created a /dev/log
socket inside the chroot). As soon as I use the 'ls' command, nothing
happens and the the process gets stuck. Listing files does work as soon as I
remove the chrootdirectory directive.

Configuration details:
From the end of the /etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Match User p16012
ChrootDirectory /srv/www/xxxxx.de
ForceCommand internal-sftp -l VERBOSE -f LOCAL6


I have created an additional socket for the rsyslog deamon inside the chroot
directory and logging works fine:
Mar 17 16:42:24 nina internal-sftp[6749]: session opened for local user
p16012 from [84.xx.xxx.66]
Mar 17 16:42:24 nina internal-sftp[6749]: received client version 3
Mar 17 16:42:24 nina internal-sftp[6749]: realpath "."
Mar 17 16:42:27 nina internal-sftp[6749]: opendir "/"

From the auth.log I get:
Mar 17 16:42:24 nina sshd[6745]: Accepted password for p16012 from
84.xx.xxx.60 port 50295 ssh2
Mar 17 16:42:24 nina sshd[6745]: pam_unix(sshd:session): session opened for
user p16012 by (uid=0)
Mar 17 16:42:24 nina sshd[6748]: subsystem request for sftp by user p16012

I also did strace the internal-sftp process:
root@nina:/srv/www/xxxxx.de# strace -s 50 -a 200 -p 6846
Process 6846 attached - interrupt to quit
select(2, [0], [], NULL, NULL)
= 1 (in [0])
read(0, "\0\0\0\20\v\0\0\177t\0\0\0\7/htdocs", 16384)
= 20
time([1395071933])
= 1395071933
socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0)
= 3
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110)
= 0
sendto(3, "<182>Mar 17 16:58:53 internal-sftp[6846]: opendir "..., 59,
MSG_NOSIGNAL, NULL, 0) = 59
close(3)
= 0
open("/htdocs", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 3
select(2, [0], [1], NULL, NULL)
= 1 (out [1])
write(1, "\0\0\0\rf\0\0\177t\0\0\0\4\0\0\0\0", 17)
= 17
select(2, [0], [], NULL, NULL)
= 1 (in [0])
read(0, "\0\0\0\r\f\0\0\177u\0\0\0\4\0\0\0\0", 16384)
= 17
getdents(3, /* 5 entries */, 32768)
= 144
lstat("/htdocs/.", {st_mode=S_IFDIR|S_ISUID|0750, st_size=52, ...})
= 0
stat("/etc/localtime", 0x7ffffaef12c0)
= -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)
geteuid()
= 6012
getegid()
= 6012
open("/etc/group", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
futex(0x7f0c0d3b61e0, FUTEX_WAIT_PRIVATE, 2, NULL

The process stays there until I kill it on the server. I can see from the
trace that the process tries to access /etc/localtime, passwd and group. Of
course those files are not present in my chroot environment and my
understanding is, that using internal-sftp does not require those.

I have found
http://unix.stackexchange.com/questions/32882/sftp-server-on-rhel6-disconnec
ts-on-ls, which is slightly comparable. I do not get disconnected and I am
on Debian, but symptoms are the same. I am using PAM with libnss-mysql.

Any help is welcome.

Thanks
Brian Rosenberger



_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Damien Miller]

On Mon, 17 Mar 2014, Brian Rosenberger wrote:

> Hi all,
>
> I am using Match directive and internal-sftp to chroot sftp users into their
> directory. Connection and login works. I can change directories and put/get
> files. Also logging of the internal sftp-process works (created a /dev/log
> socket inside the chroot). As soon as I use the 'ls' command, nothing
> happens and the the process gets stuck. Listing files does work as soon as I
> remove the chrootdirectory directive.

...

> I am using PAM with libnss-mysql.

This is likely the problem - the chrooted process is probably trying to
connect to your MySQL server and failing. You could either arrange for
MySQL to listen at the path it is expecting inside the chroot or see if
you can trick nss-mysql into giving up by creating a stale socket at
the path it is expecting.

The first approach would give you correct usernames for 'ls -l' at the
cost of potentially exposing sensitive data inside the chroot. The
latter loses usernames but keeps the chroot clean.

(all assuming this is indeed the problem)

-d

[Brian Rosenberger]

Hi Damien,

Actually I am connecting mysql via IP, so I assume it is not the connection
causing the problem, but maybe some dependencies issues. I have to say that
on another linux box (same configuration but older debian version) the
chroot setup including libnss-mysql does work. So I am missing something
else here.

Cheers
Brian