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

[Mike Buland <mike@geekgene.com>]

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