On 02/22/2010 10:19 AM, Peter Stuge wrote:
> P. Levine wrote:
>> It seems absurd to add support for chroot() in useradd and groupadd
>> without userdel and groupdel, so the patch includes support for them.
>
> gpasswd has also been mentioned. Please check what
> portage/eclass/eutils.eclass actually uses, or ideally add the flag
> to all the shadow utilities?
I did check the eclasses. Eutils calls useradd and groupadd. The only
other mention of a shadow utility is games.eclass with:
ewarn "Just run 'gpasswd -a <USER> ${GAMES_GROUP}', then have <USER>
re-login."
I would consider patching all of shadow utilities to be ideal. But I'm
not sure whether the shadow devs would. I was under the impression this
was for useradd and groupadd (and, consequently, userdel and groupdel).
I'll try to get a hold of them on IRC when I get a chance.
>
>> xfgetXXbyYY
>
> Why is all that required? It's a mess. Please explain?
>
>
> //Peter
>
>
>From my previous post:
> There are a number of calls to "getXXbyYY" functions (i.e., getgrgid,
> getpwnam, etc...). These seem to be dynamically preloaded and access
> preloaded databases. They are unaffected by chroot() (even after
> setting __nss_configure_lookup(foo, files)). I've instead used shadow's
> own method of macro expansion to generate functions doing the
> equivalent, with recursive calls to fgetXXent functions.
There are numerous calls to libc functions such as getgrgid and getpwnam
by shadow's own xgetgrgid and xgetpwnam. These are generated by files
containing macros, and at the bottom there's #include xgetXXbyYY.c, a
file the does the macro expansion. In the end, they generate wrapper
functions to initialize buffers, call the function, and duplicate and
return the struct. xgetgrgid, for instance, calls getgrgid to search
the group database for a particular gid, and returns a pointer to the
group struct if it exists. The problem is the databases are dynamically
preloaded and chroot() will not. The only mention in the glibc manual
about forcing related functions to use a particular database method is
by calling __nss_configure_lookup. Even if this did work with chroot()
it would be initializing databases from $ROOT/etc as the system
databases for the duration, which would be absurdly dangerous in a
system where other utils and libs could call on the same databases.
Glibc offers fgetXXent functions (fgetpwent, for example) which, simply,
sequentially return the next struct from a file stream supplied as the
argument. There are no fgetgrgid or fgetpwnam functions. My original
patch supplied those functions using its own xfgetXXbyYY.c and
associated macro files by recursively calling fgetXXent functions and
comparing the struct member to the argument. But after looking at
userdel.c and groupdel.c, I saw that they made calls to setXXent,
getXXent, and endXXent functions (which use the system database) that
would have changed too many lines of their code if patched. So I added
fsetXXent, fgetXXent, and fendXXent functions, and changed all the
others to, very simply, call on those.
The chroot.c file might seem like a mess but it's actually quite
organized, and if you cd to the patched source directory, configure, run
"gcc -E -I ./lib -I . -o chroot.expaded.c ./libmisc/chroot.c", and
scroll to the bottom of chroot.expaded.c, you'll see what functions
those macros expand to.
