chpst -u -/ "unable to get password/group file entry"

chpst -u -/ "unable to get password/group file entry"

[David Miller]

When I try to combine -u and -/ I get the error:
chpst: fatal: unable to get password/group file entry: file does not exist

At first I thought that it might need the passwd and group file inside the chroot but even when I copy them over chpst still fails.  I would imagine that chpst can read the passwd/group file before switching into the jail. 

Specifying the uid and gid with -u :uid:gid does work as expected. Also using -u 'username' without -/ works fine.

Heres a transcript to show what I mean, am I doing something wrong? I would like to use -u username so I don't have to lookup the uid.

Thanks!

root@desktop:/home/dave# ls -RF chroot/
chroot/:
lib/  ls*

chroot/lib:
ld-linux.so.2*  libattr.so.1*  libpthread.so.0*
libacl.so.1*    libc.so.6*     librt.so.1*

root@desktop:/home/dave# chpst -u dave -/ chroot/ /ls
chpst: fatal: unable to get password/group file entry: file does not exist

root@desktop:/home/dave# grep dave /etc/passwd
dave:x:1000:100:David Miller,,,:/home/dave:/bin/bash

root@desktop:/home/dave# mkdir chroot/etc
root@desktop:/home/dave# cp /etc/passwd /etc/group chroot/etc
root@desktop:/home/dave# chpst -u dave -/ chroot/ /ls
chpst: fatal: unable to get password/group file entry: file does not exist

root@desktop:/home/dave# rm -r chroot/etc/
root@desktop:/home/dave# chpst -u :1000:100 -/ chroot/ /ls
lib  ls

Re: chpst -u -/ "unable to get password/group file entry"

[Jack Cummings]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Mon, Aug 04, 2008 at 11:54:15AM -0500, David Miller wrote:

> When I try to combine -u and -/ I get the error:
> chpst: fatal: unable to get password/group file entry: file does not exist
 
I suspect glibc NSS[0] (name service switching). chpst is *probably* trying to
dlopen() one of the libnss_* files or /etc/nsswitch.conf. I suggest putting
strace into your chroot, and then tracing chpst. 

--Jack 

[0] NSS is also the typical argument the glibc developers use not to support
static linking. Statically linked binaries are great for chroots, because you
don't need any libraries. 

--
Jack (John) Cummings                           http://mudshark.org/
PGP fingerprint: F18B 13A3 6D06 D48A 598D  42EA 3D53 BDC8 7917 F802

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: chpst -u -/ "unable to get password/group file entry"

[David Miller]

Thanks for the suggestion.

I wonder if you could give me some pointers on how to use strace and what to look for. I'm not very familiar with it

Thanks

Jack spoke thusly:
> On Mon, Aug 04, 2008 at 11:54:15AM -0500, David Miller wrote:
> 
> > When I try to combine -u and -/ I get the error:
> > chpst: fatal: unable to get password/group file entry: file does not exist
>  
> I suspect glibc NSS[0] (name service switching). chpst is *probably* trying to
> dlopen() one of the libnss_* files or /etc/nsswitch.conf. I suggest putting
> strace into your chroot, and then tracing chpst. 
> 
> --Jack 
> 
> [0] NSS is also the typical argument the glibc developers use not to support
> static linking. Statically linked binaries are great for chroots, because you
> don't need any libraries. 
> 
> --
> Jack (John) Cummings                           http://mudshark.org/
> PGP fingerprint: F18B 13A3 6D06 D48A 598D  42EA 3D53 BDC8 7917 F802

Re: chpst -u -/ "unable to get password/group file entry"

[Mike Buland]

I've run into a similar type of problem before, sometimes when shared 
libraries are missing you can get very strange errors when entering a chroot.

I would actually recommend using "readelf -d <binary>" to find out the 
dependancies.  You can use strace, but you'll have to wade through a lot of 
garbage that's unrelated to what you're looking for.

If you use readelf, say "readelf -d /bin/bash" It will list a lot of 
information, most of which you don't care about, but the first few lines will 
look like:

 0x00000001 (NEEDED)                     Shared library: [libreadline.so.5]
 0x00000001 (NEEDED)                     Shared library: [libhistory.so.5]
 0x00000001 (NEEDED)                     Shared library: [libncursesw.so.5]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

those files at the end are the ones you need.  Unfortunately, executables as 
well as shared objects (.so files) can have dynamic dependancies, so you may 
have to check some of your .so files as well.  readelf works on them as well.

On the other hand, if you do want to use strace, you're looking for a lot of 
open function calls at the very begining, generally opening .so files, for 
example, running "strace ls 2>&1 | less" (strace outputs it's useful info on 
stderr, or fd 2) produces a lot of output, but searching for "open" you 
quickly find blocks that look like:

open("/lib/librt.so.1", O_RDONLY)       = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\35\0"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=31364, ...}) = 0
mmap2(NULL, 33356, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7f
c2000
mmap2(0xb7fc9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRIT
E, 3, 0x6) = 0xb7fc9000
close(3)                                = 0

You really only care about the open line at the top, the = 3 at the end 
indicates that the file was opened sucessfully, less than zero indicates an 
error, strace will tell you what the error was.

Honestly, I would use readelf out of the two options, but both work.  Remember 
not to run the chroot environment with strace if you do, use both of these 
options on your system normally, readelf will always list all dependancies 
weather they exist or not, but strace runs the program, and the program 
aborts after the first missing library, so you'll run into a long, iterative 
process to find all missing libraries.

Actually...I have a simple python script that will generate a complete 
dependancy list using readelf for a given binary, I just remembered.

I uploaded the file, it's simple, it just uses readelf a lot.

http://www.xagasoft.com/~eichlan/td.txt

make it executable, I would rename it to td.py, and run:

./td.py /bin/bash

This program will find the dependancies of the given file, all of it's 
dependancies' dependancies and so on until it has a complete list and prints 
it out for you.  Should come in handy :)

--Mike

On Wednesday 06 August 2008 08:39:41 pm David Miller wrote:
> Thanks for the suggestion.
>
> I wonder if you could give me some pointers on how to use strace and what
> to look for. I'm not very familiar with it
>
> Thanks
>
> Jack spoke thusly:
> > On Mon, Aug 04, 2008 at 11:54:15AM -0500, David Miller wrote:
> > > When I try to combine -u and -/ I get the error:
> > > chpst: fatal: unable to get password/group file entry: file does not
> > > exist
> >
> > I suspect glibc NSS[0] (name service switching). chpst is *probably*
> > trying to dlopen() one of the libnss_* files or /etc/nsswitch.conf. I
> > suggest putting strace into your chroot, and then tracing chpst.
> >
> > --Jack
> >
> > [0] NSS is also the typical argument the glibc developers use not to
> > support static linking. Statically linked binaries are great for chroots,
> > because you don't need any libraries.
> >
> > --
> > Jack (John) Cummings                           http://mudshark.org/
> > PGP fingerprint: F18B 13A3 6D06 D48A 598D  42EA 3D53 BDC8 7917 F802

Re: chpst -u -/ "unable to get password/group file entry"

[David Miller]

I am a bit confused as to why I even need to worry about libraries that chpst uses.  After all I want to run a daemon in the chroot, not chpst itself.  Shouldn''t chpst look up the uid and gid for -u before the chroot happens?


Also is anyone else getting failure bounce messages when they post to the list? I get two error bounces when I post but it seems that the message gets posted to the list OK.

Mike spoke thusly:
> I've run into a similar type of problem before, sometimes when shared 
> libraries are missing you can get very strange errors when entering a chroot.
> 
> I would actually recommend using "readelf -d <binary>" to find out the 
> dependancies.  You can use strace, but you'll have to wade through a lot of 
> garbage that's unrelated to what you're looking for.
> 
> If you use readelf, say "readelf -d /bin/bash" It will list a lot of 
> information, most of which you don't care about, but the first few lines will 
> look like:
> 
>  0x00000001 (NEEDED)                     Shared library: [libreadline.so.5]
>  0x00000001 (NEEDED)                     Shared library: [libhistory.so.5]
>  0x00000001 (NEEDED)                     Shared library: [libncursesw.so.5]
>  0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
> 
> those files at the end are the ones you need.  Unfortunately, executables as 
> well as shared objects (.so files) can have dynamic dependancies, so you may 
> have to check some of your .so files as well.  readelf works on them as well.
> 
> On the other hand, if you do want to use strace, you're looking for a lot of 
> open function calls at the very begining, generally opening .so files, for 
> example, running "strace ls 2>&1 | less" (strace outputs it's useful info on 
> stderr, or fd 2) produces a lot of output, but searching for "open" you 
> quickly find blocks that look like:
> 
> open("/lib/librt.so.1", O_RDONLY)       = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\35\0"..., 512) = 
> 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=31364, ...}) = 0
> mmap2(NULL, 33356, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
> 0xb7f
> c2000
> mmap2(0xb7fc9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
> MAP_DENYWRIT
> E, 3, 0x6) = 0xb7fc9000
> close(3)                                = 0
> 
> You really only care about the open line at the top, the = 3 at the end 
> indicates that the file was opened sucessfully, less than zero indicates an 
> error, strace will tell you what the error was.
> 
> Honestly, I would use readelf out of the two options, but both work.  Remember 
> not to run the chroot environment with strace if you do, use both of these 
> options on your system normally, readelf will always list all dependancies 
> weather they exist or not, but strace runs the program, and the program 
> aborts after the first missing library, so you'll run into a long, iterative 
> process to find all missing libraries.
> 
> Actually...I have a simple python script that will generate a complete 
> dependancy list using readelf for a given binary, I just remembered.
> 
> I uploaded the file, it's simple, it just uses readelf a lot.
> 
> http://www.xagasoft.com/~eichlan/td.txt
> 
> make it executable, I would rename it to td.py, and run:
> 
> ./td.py /bin/bash
> 
> This program will find the dependancies of the given file, all of it's 
> dependancies' dependancies and so on until it has a complete list and prints 
> it out for you.  Should come in handy :)
> 
> --Mike
> 
> On Wednesday 06 August 2008 08:39:41 pm David Miller wrote:
> > Thanks for the suggestion.
> >
> > I wonder if you could give me some pointers on how to use strace and what
> > to look for. I'm not very familiar with it
> >
> > Thanks
> >
> > Jack spoke thusly:
> > > On Mon, Aug 04, 2008 at 11:54:15AM -0500, David Miller wrote:
> > > > When I try to combine -u and -/ I get the error:
> > > > chpst: fatal: unable to get password/group file entry: file does not
> > > > exist
> > >
> > > I suspect glibc NSS[0] (name service switching). chpst is *probably*
> > > trying to dlopen() one of the libnss_* files or /etc/nsswitch.conf. I
> > > suggest putting strace into your chroot, and then tracing chpst.
> > >
> > > --Jack
> > >
> > > [0] NSS is also the typical argument the glibc developers use not to
> > > support static linking. Statically linked binaries are great for chroots,
> > > because you don't need any libraries.
> > >
> > > --
> > > Jack (John) Cummings                           http://mudshark.org/
> > > PGP fingerprint: F18B 13A3 6D06 D48A 598D  42EA 3D53 BDC8 7917 F802

Re: chpst -u -/ "unable to get password/group file entry"

[Mike Buland]

On Thursday 07 August 2008 02:32:34 pm David Miller wrote:
> I am a bit confused as to why I even need to worry about libraries that
> chpst uses.  After all I want to run a daemon in the chroot, not chpst
> itself.  Shouldn''t chpst look up the uid and gid for -u before the chroot
> happens?

I'm not sure if it matters pre-chroot what user you're going to be.  You have 
have the root-only (on most systems) chroot capability in order to enter a 
chroot, so my guess is that it would change user after it changed the root.  
It can't find the user info in the chroot for some reason, or there's another 
problem and you're getting an erroneous error.  Honestly, I'm not having this 
problem anywhere, so I wouldn't know, but you could give it a try.  It's the 
only thing that's really been suggested so far.

I do know that you can get some very strange error messages when using a 
chroot without all the right libs in it, but I don't know why you're getting 
your error.

> Also is anyone else getting failure bounce messages when they post to the
> list? I get two error bounces when I post but it seems that the message
> gets posted to the list OK.

I'm not getting any...

> Mike spoke thusly:
> > I've run into a similar type of problem before, sometimes when shared
> > libraries are missing you can get very strange errors when entering a
> > chroot.
> >
> > I would actually recommend using "readelf -d <binary>" to find out the
> > dependancies.  You can use strace, but you'll have to wade through a lot
> > of garbage that's unrelated to what you're looking for.
> >
> > If you use readelf, say "readelf -d /bin/bash" It will list a lot of
> > information, most of which you don't care about, but the first few lines
> > will look like:
> >
> >  0x00000001 (NEEDED)                     Shared library:
> > [libreadline.so.5] 0x00000001 (NEEDED)                     Shared
> > library: [libhistory.so.5] 0x00000001 (NEEDED)                     Shared
> > library: [libncursesw.so.5] 0x00000001 (NEEDED)                    
> > Shared library: [libdl.so.2] 0x00000001 (NEEDED)                    
> > Shared library: [libc.so.6]
> >
> > those files at the end are the ones you need.  Unfortunately, executables
> > as well as shared objects (.so files) can have dynamic dependancies, so
> > you may have to check some of your .so files as well.  readelf works on
> > them as well.
> >
> > On the other hand, if you do want to use strace, you're looking for a lot
> > of open function calls at the very begining, generally opening .so files,
> > for example, running "strace ls 2>&1 | less" (strace outputs it's useful
> > info on stderr, or fd 2) produces a lot of output, but searching for
> > "open" you quickly find blocks that look like:
> >
> > open("/lib/librt.so.1", O_RDONLY)       = 3
> > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\35\0"...,
> > 512) = 512
> > fstat64(3, {st_mode=S_IFREG|0755, st_size=31364, ...}) = 0
> > mmap2(NULL, 33356, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
> > = 0xb7f
> > c2000
> > mmap2(0xb7fc9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
> > MAP_DENYWRIT
> > E, 3, 0x6) = 0xb7fc9000
> > close(3)                                = 0
> >
> > You really only care about the open line at the top, the = 3 at the end
> > indicates that the file was opened sucessfully, less than zero indicates
> > an error, strace will tell you what the error was.
> >
> > Honestly, I would use readelf out of the two options, but both work. 
> > Remember not to run the chroot environment with strace if you do, use
> > both of these options on your system normally, readelf will always list
> > all dependancies weather they exist or not, but strace runs the program,
> > and the program aborts after the first missing library, so you'll run
> > into a long, iterative process to find all missing libraries.
> >
> > Actually...I have a simple python script that will generate a complete
> > dependancy list using readelf for a given binary, I just remembered.
> >
> > I uploaded the file, it's simple, it just uses readelf a lot.
> >
> > http://www.xagasoft.com/~eichlan/td.txt
> >
> > make it executable, I would rename it to td.py, and run:
> >
> > ./td.py /bin/bash
> >
> > This program will find the dependancies of the given file, all of it's
> > dependancies' dependancies and so on until it has a complete list and
> > prints it out for you.  Should come in handy :)
> >
> > --Mike
> >
> > On Wednesday 06 August 2008 08:39:41 pm David Miller wrote:
> > > Thanks for the suggestion.
> > >
> > > I wonder if you could give me some pointers on how to use strace and
> > > what to look for. I'm not very familiar with it
> > >
> > > Thanks
> > >
> > > Jack spoke thusly:
> > > > On Mon, Aug 04, 2008 at 11:54:15AM -0500, David Miller wrote:
> > > > > When I try to combine -u and -/ I get the error:
> > > > > chpst: fatal: unable to get password/group file entry: file does
> > > > > not exist
> > > >
> > > > I suspect glibc NSS[0] (name service switching). chpst is *probably*
> > > > trying to dlopen() one of the libnss_* files or /etc/nsswitch.conf. I
> > > > suggest putting strace into your chroot, and then tracing chpst.
> > > >
> > > > --Jack
> > > >
> > > > [0] NSS is also the typical argument the glibc developers use not to
> > > > support static linking. Statically linked binaries are great for
> > > > chroots, because you don't need any libraries.
> > > >
> > > > --
> > > > Jack (John) Cummings                           http://mudshark.org/
> > > > PGP fingerprint: F18B 13A3 6D06 D48A 598D  42EA 3D53 BDC8 7917 F802

Re: chpst -u -/ "unable to get password/group file entry"

[David Miller]

Indeed it was looking for the libnss libraries and /etc/nsswitch.conf as Jack suspected. Mike's td.py script didn't find the nss library dependency, neither does ldd.

Looking at the source and the strace, the chroot happens before the suidgid. And the uid/gid is looked up at the same time as the suidgid. I just wasn't expecting it to work this way.

the -U workaround seems to do the trick, Thanks paul.

Paul spoke thusly:
> David Miller <dave@frop.net> wrote:
> > I wonder if you could give me some pointers on how to use strace and
> > what to look for. I'm not very familiar with it
> 
> You don't need to copy strace into the chroot area.  Just run:
> strace chpst -u dave -/ chroot /ls
> 
> strace will output a lot of information, but the interesting bit will
> be near the end.  Just before the error message appears, you should
> see one of more failed open() calls.  That will tell you what files
> are missing.
> 
> Or you could work around the problem like this:
> chpst -U dave sh -c 'exec chpst -u ":$UID:$GID" -/ chroot /ls'
> 
> > Shouldn''t chpst look up the uid and gid for -u before the chroot
> > happens?
> 
> That's probably a good idea, but in fact it doesn't do that.
> 
> 
> paul

Re: chpst -u -/ "unable to get password/group file entry"

[Mike Buland]

On Thursday 07 August 2008 03:25:48 pm David Miller wrote:
> Indeed it was looking for the libnss libraries and /etc/nsswitch.conf as
> Jack suspected. Mike's td.py script didn't find the nss library dependency,
> neither does ldd.

That's true, if it was a libnss issue it wouldn't, in order to make those more 
dynamic and easily changable while a system is running (is my understanding) 
the name service switch libraries are not loaded at link time, but as plugins 
at runtime, only strace would help with that.  Sorry, I totally spaced on 
that.

Of course that makes sense, it's the error you get whenever you write a 
program that uses the libc passwd interfaces and try to make it static.

> Looking at the source and the strace, the chroot happens before the
> suidgid. And the uid/gid is looked up at the same time as the suidgid. I
> just wasn't expecting it to work this way.
>
> the -U workaround seems to do the trick, Thanks paul.
>
> Paul spoke thusly:
> > David Miller <dave@frop.net> wrote:
> > > I wonder if you could give me some pointers on how to use strace and
> > > what to look for. I'm not very familiar with it
> >
> > You don't need to copy strace into the chroot area.  Just run:
> > strace chpst -u dave -/ chroot /ls
> >
> > strace will output a lot of information, but the interesting bit will
> > be near the end.  Just before the error message appears, you should
> > see one of more failed open() calls.  That will tell you what files
> > are missing.
> >
> > Or you could work around the problem like this:
> > chpst -U dave sh -c 'exec chpst -u ":$UID:$GID" -/ chroot /ls'
> >
> > > Shouldn''t chpst look up the uid and gid for -u before the chroot
> > > happens?
> >
> > That's probably a good idea, but in fact it doesn't do that.
> >
> >
> > paul