Change History (9)
comment:1 by , 18 years ago
Description: | modified (diff) |
---|
comment:2 by , 18 years ago
Well, hello Jeremy.
I haven't tried this in my build. In fact, it's been quite a while since I did anything with the base build as I've been trying to concentrate on BLFS when I have time.
Anyway, I think installing a temp su from Ch. 5 coreutils is not a bad idea. But, see the fat warning Greg put up about doing this:
http://www.diy-linux.org/x86-reference-build/temptools.html#tt-coreutils
If this is gonna be done, it would probably be better to install it as sutemp or su-tools or something. We don't want people freaking out that their su doesn't work anymore. After that, you can see what Greg does to drop privileges for bash:
http://www.diy-linux.org/x86-reference-build/chroot.html#c-bash
comment:3 by , 18 years ago
Howdy Dan.
How about calling it 'tsu'? :) As you say, naming it something different would avoid that entire situation.
comment:4 by , 18 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 18 years ago
Summary: | base - test suite should not be run as root → bash - test suite should not be run as root |
---|
Think this ticket was meant to say 'bash'...
comment:7 by , 18 years ago
Is this enough for the coreutils testsuite? I thought it needed two unprivileged groups; we currently only have one (nogroup, with GID 99). I know we created two groups before this patch, and the dummy user was a member of both.
But maybe I'm not remembering the requirements correctly.
comment:8 by , 18 years ago
Nice catch. I did check the results of the tests, but failed to notice the reason why certain ones were skipped. I just saw that nothing failed. When using the nobody user who is a member of just the one group, we get messages like:
Making check in chgrp make[2]: Entering directory `/root/coreutils-6.7/tests/chgrp' make check-TESTS make[3]: Entering directory `/root/coreutils-6.7/tests/chgrp' ./no-x: this test requires that you be a member of more than one group, but running `id -G' either failed or found just one. If you really are a member of at least two groups, then rerun this test with COREUTILS_GROUPS set in your environment to the space-separated list of group names or numbers. E.g., env COREUTILS_GROUPS='users cdrom' make check
So it skips that test. I'll add the addition of the extra dummy group back in and make nobody a part of it.
I read through the above thread. I don't think it's worth trying to move shadow up in the build order - it ends up just creating more work and testing for little gain. I'd rather we do something like DIY does and install 'su' from chapter 5.
Dan, do you have this set up already somewhere in your builds? If not, I might be able to throw together a patch.