Opened 17 years ago

Closed 16 years ago

Last modified 16 years ago

#1877 closed defect (fixed)

bash - test suite should not be run as root

Reported by: peter Owned by: Jeremy Huntwork
Priority: normal Milestone:
Component: Book Version: SVN
Severity: normal Keywords:

Description (last modified by Jeremy Huntwork)

Change History (9)

comment:1 by Jeremy Huntwork, 17 years ago

Description: modified (diff)

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.

comment:2 by dnicholson@…, 17 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:

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:

comment:3 by Jeremy Huntwork, 17 years ago

Howdy Dan.

How about calling it 'tsu'? :) As you say, naming it something different would avoid that entire situation.

comment:4 by Jeremy Huntwork, 17 years ago

Owner: changed from lfs-book@… to Jeremy Huntwork
Status: newassigned

comment:5 by Jeremy Huntwork, 17 years ago

Summary: base - test suite should not be run as rootbash - test suite should not be run as root

Think this ticket was meant to say 'bash'...

comment:6 by Jeremy Huntwork, 16 years ago

Resolution: fixed
Status: assignedclosed

Fixed as of r8006.

comment:7 by, 16 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 Jeremy Huntwork, 16 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.

comment:9 by Jeremy Huntwork, 16 years ago

Milestone: 6.3

Milestone 6.3 deleted

Note: See TracTickets for help on using tickets.