Bug#611878: rssh mkchroot.sh sample script broken

[Russ Allbery]

"Erich Liebmann"  writes:

> Fantastic, thanks a lot, appreciate!

> I just downloaded rssh_2.3.3-1_i386.deb from the incoming folder [1] and
> used the 'mkchroot.sh' script contained in it to re-create the chroot
> environment. It's now working nicely without any issues. In other words,
> I can confirm that the fix is working!

Excellent, thank you for the verification!

> Thanks a lot for getting this fixed so quickly. One would wish for such
> quick turnaround times with some commercial vendors ;-)

> Do you know when rssh_2.3.3-1_i386.deb will be available in stable? (Is
> this going to be with the next point release)?

Unfortunately for the timing of this, Debian generally doesn't change
stable packages once they've been released except for serious bugs, and
changes to an example script like this one probably doesn't qualify for a
stable update.

For good or ill, the mkchroot script (both in the Debian package and
upstream) isn't really part of the "installed" rssh package, but rather
was intended by upstream to be an example that people may need to modify.
Over time, various people working on it have made it more robust, but I
suspect most rssh users aren't using a chroot, so it doesn't get a lot of
testing.

So the short version is that normally this wouldn't make it into a stable
release.  I could fairly easily prepare a backport for
backports.debian.org if that would help, though.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Erich Liebmann]

> I'll upload a new package to unstable shortly.  I also need 
> to incorporate
> the new upstream release.

Fantastic, thanks a lot, appreciate!

I just downloaded rssh_2.3.3-1_i386.deb from the incoming folder [1] and
used the 'mkchroot.sh' script contained in it to re-create the chroot
environment. It's now working nicely without any issues. In other words, I
can confirm that the fix is working!

Thanks a lot for getting this fixed so quickly. One would wish for such
quick turnaround times with some commercial vendors ;-)

Do you know when rssh_2.3.3-1_i386.deb will be available in stable? (Is this
going to be with the next point release)?

Cheers
Erich

[1] http://incoming.debian.org/rssh_2.3.3-1_i386.deb




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Russ Allbery]

"Erich Liebmann"  writes:

> Maybe I focused too much on describing the solution I found to fix the
> issue rather than the problem itself. Please find a description of the
> problem / symptoms below.

> After setting up the rssh chroot environment with the 'mkchroot.sh'
> script I tried to login with 'sftp' and always got 'Connection
> closed'. I inspected the logs on the server and noticed the following
> log entries (each time I made a login attempt):

Ah, thank you -- sftp was one of the key things that I needed to reproduce
what you were doing.  (I was trying scp, which had different symptoms.)

I've confirmed that the missing libnsl library causes those symptoms for
sftp and adding libnsl was the only change required to the chroot for sftp
to be happy again.  The other libraries don't appear to be needed.

If you want to do Subversion, rsync, rdist, or CVS, more libraries will be
needed, but it looks like the script never handled that.  I'm not sure
what to do about that, but for the next release I'll probably punt and
just fix the scp/sftp issue.

I'll upload a new package to unstable shortly.  I also need to incorporate
the new upstream release.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Erich Liebmann]

Maybe I focused too much on describing the solution I found to fix the issue
rather than the problem itself. Please find a description of the problem /
symptoms below.

After setting up the rssh chroot environment with the 'mkchroot.sh' script I
tried to login with 'sftp' and always got 'Connection closed'. I inspected
the logs on the server and noticed the following log entries (each time I
made a login attempt):

  sshd[9324]: Accepted keyboard-interactive/pam for  from
 port  ssh2
  sshd[9328]: (pam_unix) session opened for user  by
(uid=0)
  sshd[9328]: subsystem request for sftp
  rssh[9329]: chroot cmd line: /usr/lib/rssh/rssh_chroot_helper
2 "/usr/lib/openssh/sftp-server"
  sshd[9328]: (pam_unix) session closed for user rssh-erich

No error, no indication what might be wrong. I then googled to see what
might be the reason for this and came across an RSSH FAQ [1] which described
the problem as being related to an incorrectly setup chroot environment.

I then compared the chroot environment created by 'mkchroot.sh' on the lenny
system with the one on the 'squeeze' system and found out that 'mkchroot.sh'
didn't copy the same libraries into the chroot environment. After manually
copying said libraries to the chroot environment it started to work.

Hence, we can conclude that the error 'Connection closed' is caused by a
failure to invoke /usr/lib/rssh/rssh_chroot_helper 2
"/usr/lib/openssh/sftp-server" which is due to missing library dependencies.

[1] http://www.pizzashack.org/rssh/faq.shtml#6



> -Original Message-
> From: Russ Allbery [mailto:r...@debian.org] 
> Sent: Thursday, 24 February, 2011 12:39
> To: Erich Liebmann
> Cc: 611...@bugs.debian.org
> Subject: Re: Bug#611878: rssh mkchroot.sh sample script broken
> 
> "Erich Liebmann"  writes:
> 
> > As mentioned in my previous email, I got the chroot 
> environment working
> > by manually copying over a number of _required_ libraries.  
> Please note
> > that "required libraries" in this context refers to 
> libraries required
> > by the chroot environment to work properly and not 
> necessarily (only)
> > the dependencies of the binaries passed to 'ldd' in the 
> 'mkchroot.sh'
> > script. So maybe the 'mkchroot.sh' script simply passes an 
> an incomplete
> > list of binaries to 'ldd'?
> 
> In the absence of any sort of error message or clue as to what problem
> you're encountering, it's kind of hard to tell.
> 
> > Would be great if the 'mkchroot.sh' script could copy _all_ required
> > libraries into the chroot environment, hence produce a 
> _working_ chroot
> > environment (as it used to be on lenny).
> 
> Yes, absolutely, that's the goal.
> 
> > Unfortunately, I am unable to suggest or provide a fix since I don't
> > fully understand why 'mkchroot.sh' or 'ldd' do not correctly detect
> > _all_ required libraries on squeeze.
> 
> I don't need you to come up with that, although of course 
> that would be
> great.  But I'd settle for just an explanation of what wasn't 
> working, how
> you found that it wasn't working, and what the symptoms were.  :)
> 
> > I still believe it might have to do with the fact that ssh 
> libraries are
> > already loaded and cached when logging in remotely. Did you log in
> > remotely via ssh to the systems you checked?
> 
> I was really kind of hoping, given that you already had this 
> all set up
> and were encountering a problem, that I could get you to at 
> least send me
> an error message or something.  :)  But sure, I went ahead 
> and set up a
> test environment for a chroot and found one problem: the nss 
> libraries now
> are linked with libnsl, and the current script doesn't find that.
> 
> Once I copied libnsl into the chroot, and I'll fix 
> mkchroot.sh to look for
> that case, scp worked fine with a chroot created by mkchroot.sh.
> 
> If you're having other problems beyond needing that one additional
> library, you're going to have to throw me a bone here and 
> give me at least
> *some* clue about exactly what's failing for you
> 
> -- 
> Russ Allbery (r...@debian.org)   
> <http://www.eyrie.org/~eagle/>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.872 / Virus Database: 271.1.1/3440 - Release 
> Date: 02/24/11 03:34:00
> 




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Russ Allbery]

"Erich Liebmann"  writes:

> As mentioned in my previous email, I got the chroot environment working
> by manually copying over a number of _required_ libraries.  Please note
> that "required libraries" in this context refers to libraries required
> by the chroot environment to work properly and not necessarily (only)
> the dependencies of the binaries passed to 'ldd' in the 'mkchroot.sh'
> script. So maybe the 'mkchroot.sh' script simply passes an an incomplete
> list of binaries to 'ldd'?

In the absence of any sort of error message or clue as to what problem
you're encountering, it's kind of hard to tell.

> Would be great if the 'mkchroot.sh' script could copy _all_ required
> libraries into the chroot environment, hence produce a _working_ chroot
> environment (as it used to be on lenny).

Yes, absolutely, that's the goal.

> Unfortunately, I am unable to suggest or provide a fix since I don't
> fully understand why 'mkchroot.sh' or 'ldd' do not correctly detect
> _all_ required libraries on squeeze.

I don't need you to come up with that, although of course that would be
great.  But I'd settle for just an explanation of what wasn't working, how
you found that it wasn't working, and what the symptoms were.  :)

> I still believe it might have to do with the fact that ssh libraries are
> already loaded and cached when logging in remotely. Did you log in
> remotely via ssh to the systems you checked?

I was really kind of hoping, given that you already had this all set up
and were encountering a problem, that I could get you to at least send me
an error message or something.  :)  But sure, I went ahead and set up a
test environment for a chroot and found one problem: the nss libraries now
are linked with libnsl, and the current script doesn't find that.

Once I copied libnsl into the chroot, and I'll fix mkchroot.sh to look for
that case, scp worked fine with a chroot created by mkchroot.sh.

If you're having other problems beyond needing that one additional
library, you're going to have to throw me a bone here and give me at least
*some* clue about exactly what's failing for you

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Erich Liebmann]

Thanks for your reply Russ.  

As mentioned in my previous email, I got the chroot environment working by
manually copying over a number of _required_ libraries. Please note that
"required libraries" in this context refers to libraries required by the
chroot environment to work properly and not necessarily (only) the
dependencies of the binaries passed to 'ldd' in the 'mkchroot.sh' script. So
maybe the 'mkchroot.sh' script simply passes an an incomplete list of
binaries to 'ldd'?

Would be great if the 'mkchroot.sh' script could copy _all_ required
libraries into the chroot environment, hence produce a _working_ chroot
environment (as it used to be on lenny). Unfortunately, I am unable to
suggest or provide a fix since I don't fully understand why 'mkchroot.sh' or
'ldd' do not correctly detect _all_ required libraries on squeeze.

I still believe it might have to do with the fact that ssh libraries are
already loaded and cached when logging in remotely. Did you log in remotely
via ssh to the systems you checked?


> -Original Message-
> From: Russ Allbery [mailto:r...@debian.org] 
> Sent: Tuesday, 22 February, 2011 13:16
> To: Erich Liebmann
> Cc: 611...@bugs.debian.org
> Subject: Re: Bug#611878: rssh mkchroot.sh sample script broken
> 
> "Erich Liebmann"  writes:
> 
> > After trying 'ldd' with other binaries I am not sure 
> whether, the fact
> > that only 'libc' is reported as a shared library dependency 
> for 'scp'
> > and 'sftp-server', is related to VDSO, to the way the 'scp' and
> > 'sftp-server' binaries were created in the first place, or 
> some other
> > factors.
> 
> I'm fairly sure that scp and sftp-server themselves just 
> don't depend on
> any libraries other than libc and the dynamic loader.  Checking a few
> different systems, they don't seem to.  And there isn't any reason why
> they should need to; they don't do any cryptography.  That's 
> all done by
> the ssh binary.
> 
> > Interestingly even 'readelf' reports only the 'libc' 
> dependency for 'scp':
> 
> > # readelf -d /usr/bin/scp | egrep NEEDED
> >  0x0001 (NEEDED) Shared library: [libc.so.6]
> > #
> 
> That confirms that it definitely doesn't need other libraries.
> 
> > I just know that on my old 'lenny' installation 'ldd' 
> reported shared
> > library dependencies for 'scp' and 'sftp-server' corretly and
> > 'mkchroot.sh' created a working chroot environment. For some unkown
> > reason this does not seem to be the case any more on my new 
> 'squeeze'
> > machine!
> 
> What exactly doesn't work about the chroot environment?  Maybe we're
> chasing the wrong thing.
> 
> > I doubt that 'scp' depends only on 'libc', at least on my 
> old 'lenny'
> > installation it had several other dependencies, including 
> 'libcrypt' and
> > 'libnsl'.
> 
> I suspect this was a cleanup of the build system.
> 
> I don't think there are any fixes required to mkchroot, at 
> least for those
> particular binaries.  There's probably some fix required for 
> *something*
> you're running into, but I think the ldd output is a red 
> herring.  If you
> could provide more information about what doesn't work in the 
> chroot, that
> would be helpful in finding whatever the actual issue is.
> 
> -- 
> Russ Allbery (r...@debian.org)   
> <http://www.eyrie.org/~eagle/>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.872 / Virus Database: 271.1.1/3440 - Release 
> Date: 02/21/11 16:05:00
> 




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Russ Allbery]

"Erich Liebmann"  writes:

> After trying 'ldd' with other binaries I am not sure whether, the fact
> that only 'libc' is reported as a shared library dependency for 'scp'
> and 'sftp-server', is related to VDSO, to the way the 'scp' and
> 'sftp-server' binaries were created in the first place, or some other
> factors.

I'm fairly sure that scp and sftp-server themselves just don't depend on
any libraries other than libc and the dynamic loader.  Checking a few
different systems, they don't seem to.  And there isn't any reason why
they should need to; they don't do any cryptography.  That's all done by
the ssh binary.

> Interestingly even 'readelf' reports only the 'libc' dependency for 'scp':

> # readelf -d /usr/bin/scp | egrep NEEDED
>  0x0001 (NEEDED) Shared library: [libc.so.6]
> #

That confirms that it definitely doesn't need other libraries.

> I just know that on my old 'lenny' installation 'ldd' reported shared
> library dependencies for 'scp' and 'sftp-server' corretly and
> 'mkchroot.sh' created a working chroot environment. For some unkown
> reason this does not seem to be the case any more on my new 'squeeze'
> machine!

What exactly doesn't work about the chroot environment?  Maybe we're
chasing the wrong thing.

> I doubt that 'scp' depends only on 'libc', at least on my old 'lenny'
> installation it had several other dependencies, including 'libcrypt' and
> 'libnsl'.

I suspect this was a cleanup of the build system.

I don't think there are any fixes required to mkchroot, at least for those
particular binaries.  There's probably some fix required for *something*
you're running into, but I think the ldd output is a red herring.  If you
could provide more information about what doesn't work in the chroot, that
would be helpful in finding whatever the actual issue is.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Erich Liebmann]

Thanks for your reply! Please find my answer inline...


> > The "mkchroot.sh" sample script that comes with package 
> "rssh" relies on
> > "ldd" to determine the shared library dependencies subject 
> to be copied
> > to the chroot environment. Unfortunately "ldd" reports an incomplete
> > list of shared library dependencies since the introduction 
> of Virtual
> > Dynamic Shared Objects (linux-vdso.so).
> 
> > # ldd /usr/bin/scp
> > linux-vdso.so.1 =>  (0x7fff4bdff000)
> > libc.so.6 => /lib/libc.so.6 (0x7fcaa7e31000)
> > /lib64/ld-linux-x86-64.so.2 (0x7fcaa83a8000)
> > #
> 
> > Kindly adjust the "mkchroot.sh" script to work on Linux systems with
> > VDSO enabled
> 
> Happy to do so as soon as someone tells me how.  :)  I've 
> never heard of
> VDSO before and have no idea how to convince ldd to actually 
> provide the
> required information.

After trying 'ldd' with other binaries I am not sure whether, the fact that
only 'libc' is reported as a shared library dependency for 'scp' and
'sftp-server', is related to VDSO, to the way the 'scp' and 'sftp-server'
binaries were created in the first place, or some other factors.

'ldd' seems to correctly report all shared library dependencies for other
binaries from the same package (e.g. 'ssh-keygen'):

# ldd /usr/bin/ssh-keygen
linux-vdso.so.1 =>  (0x7a3ff000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
(0x7f96ae0f9000)
libdl.so.2 => /lib/libdl.so.2 (0x7f96adef5000)
libresolv.so.2 => /lib/libresolv.so.2 (0x7f96adcde000)
libc.so.6 => /lib/libc.so.6 (0x7f96ad97d000)
libz.so.1 => /usr/lib/libz.so.1 (0x7f96ad766000)
/lib64/ld-linux-x86-64.so.2 (0x7f96ae6cb000)
#

Maybe VDSO caches shared library dependencies only for those binaries that
are currently loaded into memory? Since I login via 'ssh' it's possible that
some of the binaries are already loaded, causing the dependencies to be
cached as VDSO, and resulting in 'ldd' to not report them?

Interestingly even 'readelf' reports only the 'libc' dependency for 'scp':

# readelf -d /usr/bin/scp | egrep NEEDED
 0x0001 (NEEDED) Shared library: [libc.so.6]
#

I just know that on my old 'lenny' installation 'ldd' reported shared
library dependencies for 'scp' and 'sftp-server' corretly and 'mkchroot.sh'
created a working chroot environment. For some unkown reason this does not
seem to be the case any more on my new 'squeeze' machine!

 
> > or advise (document) which commands can be used to 
> determine the full
> > set of dynamic library dependencies required for manual 
> creation of the
> > chroot environment.
> 
> Just to check, are you sure that your /usr/bin/scp is 
> actually linked with
> any other libraries?  Mine isn't:
> 
> windlord:~> ldd /usr/bin/scp
> linux-gate.so.1 =>  (0xb76e6000)
> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb757d000)
> /lib/ld-linux.so.2 (0xb76e7000)

I doubt that 'scp' depends only on 'libc', at least on my old 'lenny'
installation it had several other dependencies, including 'libcrypt' and
'libnsl'.


> If the problem is just that the chroot script needs to ignore
> linux-vdso.so.1 the way that it ignores linux-gate.so.1, that's a very
> easy fix.

I got the chroot environment working by manually copying the following
libraries to the chroot environment: /lib/libcom_err.so.2,
/lib/libcrypt.so.1, /lib/libdl.so.2, /lib/libkeyutils.so.1,
/lib/libnsl.so.1, /lib/libpthread.so.0, /lib/libresolv.so.2,
/lib/libutil.so.1, /usr/lib/libcrypto.so.0.9.8,
/usr/lib/libgssapi_krb5.so.2, /usr/lib/libkrb5.so.3,
/usr/lib/libkrb5support.so.0, /usr/lib/libz.so.1. I compiled the list of
required libraries based on the 'ldd' output on my old machine running
'lenny'. Not sure how to get the same information on a 'squeeze'
installation?!?




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Russ Allbery]

"Erich Liebmann"  writes:

> The "mkchroot.sh" sample script that comes with package "rssh" relies on
> "ldd" to determine the shared library dependencies subject to be copied
> to the chroot environment. Unfortunately "ldd" reports an incomplete
> list of shared library dependencies since the introduction of Virtual
> Dynamic Shared Objects (linux-vdso.so).

> # ldd /usr/bin/scp
> linux-vdso.so.1 =>  (0x7fff4bdff000)
> libc.so.6 => /lib/libc.so.6 (0x7fcaa7e31000)
> /lib64/ld-linux-x86-64.so.2 (0x7fcaa83a8000)
> #

> Kindly adjust the "mkchroot.sh" script to work on Linux systems with
> VDSO enabled

Happy to do so as soon as someone tells me how.  :)  I've never heard of
VDSO before and have no idea how to convince ldd to actually provide the
required information.

> or advise (document) which commands can be used to determine the full
> set of dynamic library dependencies required for manual creation of the
> chroot environment.

Just to check, are you sure that your /usr/bin/scp is actually linked with
any other libraries?  Mine isn't:

windlord:~> ldd /usr/bin/scp
linux-gate.so.1 =>  (0xb76e6000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb757d000)
/lib/ld-linux.so.2 (0xb76e7000)

If the problem is just that the chroot script needs to ignore
linux-vdso.so.1 the way that it ignores linux-gate.so.1, that's a very
easy fix.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611878: rssh mkchroot.sh sample script broken

[Erich Liebmann]

Package: rssh
Version: 2.3.2-13

The "mkchroot.sh" sample script that comes with package "rssh" relies on
"ldd" to determine the shared library dependencies subject to be copied to
the chroot environment. Unfortunately "ldd" reports an incomplete list of
shared library dependencies since the introduction of Virtual Dynamic Shared
Objects (linux-vdso.so).

# ldd /usr/bin/scp
linux-vdso.so.1 =>  (0x7fff4bdff000)
libc.so.6 => /lib/libc.so.6 (0x7fcaa7e31000)
/lib64/ld-linux-x86-64.so.2 (0x7fcaa83a8000)
#

Kindly adjust the "mkchroot.sh" script to work on Linux systems with VDSO
enabled or advise (document) which commands can be used to determine the
full set of dynamic library dependencies required for manual creation of the
chroot environment.

Best Regards
Erich




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org