PLFS coreutils checks (was Re: Updated buildscripts (v2.2.8))

Bill's LFS Login lfsbill at wlmcs.com
Tue Apr 22 16:30:29 PDT 2003


On Wed, 23 Apr 2003, Erik-Jan wrote:

> Ryan.Oliver at pha.com.au wrote:
> >
> > why not use
> > for name in $names; do
> >   retname=`su 'id -un' $name
> >   test "$name" = "$retname" && { non_root_username=$name; break; }
> > done
> >
>
> shouldn't this be:
>    retname=`su -c 'id -un' $name`
>
> > at the least its a valid check if the shell is actually a shell, and double
> > checks that the user reports itself correctly.
>
> This works nicely, but still gives trouble when the first user with a
> valid shell has /bin/bash, because it then tries to read /root/.bashrc
> and it doesn't have permission to do so. It passes as a valid shell
> though, but when the rm-test is done, the extra permission-error output
> screws up the test.
>
> I can think of three solutions:
> 1) unsetting BASH_ENV before the su in both the valid-shell and the
> rm-test. It is just plain ugly, and who knows what kind of ENV-issues
> will emerge when user other shells than bash.
> 2) using --shell=/bin/sh in both the valid-shell and the rm-test. It
> works, most systems will have a /bin/sh, but it bypasses the whole
> find-a-valid-shell-test. Most likely it will use bin (in ch5) or nobody
> (in ch6) and that just doesn't feel good.
> 3) sending the bash-error in the valid-shell test to /dev/null like
> this:
>     retname=`su -c 'id -un' $name 2>/dev/null`
>    and doing the rm-test with --shell=/bin/sh, because then you know for
> sure how the shell behaves.

4) *If* my tests (in an admittedly uncertain environment at the time)
are any indication, rearranging the su statement will also suppress the
reading of the /root/.bashrc. I'll know for sure late tonight when my
new test with a known-good environment. The sed that modifies
fail-2eperm in the junk I sent earlier implements this and did work in
the environment at that time.

> >
> > Of course wont work on solaris <snip>

> I vote 3. :))

I abstain until I know the ins-and-outs of what I've done, what you
mention above and test/investigation of your BASH_ENV discovery. My
*leaning* is towards 4, if it proves out because it changes the su
commands to match the current man pages, offers a "real fix" (that is,
the developer can apply this to his source). But that is all presumptive
reasoning by me, which may be just hot-air.

BTW, I would have done a patch, but RO has expressed a preference for
sed, so that's what I did.

> Bye
> Erik-Jan

-- 
Bill Maltby
lfsbill at wlmcs.com

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list