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