Updated buildscripts (v2.2.8)

Bill's LFS Login lfsbill at wlmcs.com
Mon Apr 21 10:38:39 PDT 2003


erik, saw your recent post and had just finished this one. So I decided
to post it so that you also have the information I garnered. Let's post
again with a preferred/best/combination solution (I'll try your stuff
too) that addresses all the issues we find.

I see your fix may address the user test failure, so I do your stuff and
hope that fixes that.

Anyway, here's my epistle.

On Sun, 20 Apr 2003, Bill's LFS Login wrote:

> On Sun, 20 Apr 2003, Bill's LFS Login wrote:
>
> > On Sun, 20 Apr 2003, Erik-Jan wrote:
> >
> > > Bill's LFS Login wrote:
> > ><snip>
>
> > > Can you try the manual test again in src, with su and/or /stage1/bin/su?
> >
> > Yep. I was in tests/rm looking at scripts and forgot to cd. Will do the
> > tests again. Away for a few hours - be late tonight (your time) before
> > I can do it again. I suspect the su part will act the same though.
>
> <snip>

> Methinks there is a secret link somewhere laddie! Maybe Greg or Ryan or
> someone knows the cause of this? After all, the whole point of the new
> PATH setting was to cause /stage1 stuff to be automatically found before
> the stuff from the host system.
>
> <snip>

An interesting exercise, which lead me to a potential solution of the su
problem that I'm experiencing.

I (and Erik, Greg, Ryan, Ronald too I think) would be interested in the
results of running this little script, and your config. I'm on an LFS
4.0 (2002-10-29 cvs), kernel 2.4.19 and env shows BASH_VER=2.05b in my
su'd to root shell, but my shell before and after su'ing to root shows
BASH_VERSION='2.05a.0(1)-release'. Is that interesting? Keep in mind
that I have run up to, but not including, the coreutils chapter 5 stuff
from Ryan's scripts, with oddball (and by now indeterminate changes).
:-\

.../src# /lib/libc.so.6 yields  version 2.2.5
.../src# gcc --version yields gcc (GCC) 3.2.2

Anyway, when I run this script while su'd to root:

cd /mnt/lfs/usr/src/coreutils-5.0/src

mkdir a;chmod 1777 a;touch a/b
su lfsbill -c 'id;./rm -rf a'

mkdir a;chmod 1777 a;touch a/b
su -c 'id;./rm -rf a' lfsbill

mkdir a;chmod 1777 a;touch a/b
./su lfsbill -c 'id;./rm -rf a'

mkdir a;chmod 1777 a;touch a/b
./su -c 'id;./rm -rf a' lfsbill

I get this result

  uid=505(lfsbill) gid=505(lfsbill) groups=505(lfsbill)
  ./rm: cannot remove `a': Permission denied
  mkdir: cannot create directory `a': File exists
  uid=0(root) gid=0(root) groups=0(root)
  bash: /root/.bashrc: Permission denied
  uid=505(lfsbill) gid=505(lfsbill) groups=505(lfsbill)
  ./rm: cannot remove `a': Permission denied
  mkdir: cannot create directory `a': File exists
  bash: /root/.bashrc: Permission denied
  uid=505(lfsbill) gid=505(lfsbill) groups=505(lfsbill)
  ./rm: cannot remove `a': Permission denied

Note that the instances with the user name *before* the -c stuff works
as expected and the ones with the user name *after* the -c stuff does
not give the expected result. Interesting? Can anyone duplicate this
behaviour? Is it something I did? I guess I shouldn't be surprised since
the recent man versions show the user before certain options and after
certain other options. This is a recent (in terms of decades) change.
Check out the man su pages. Should this be passed "upstream"?

I also ran this way as user nobody with similar results. So, I (we?) and
the test developer have been snookered by using the same-old-same-old
when (apparently) the operation of the command has changed somewhere in
the past.

Now, after much angst resulting from additional experimentation, I found
a combination of changes that seems to run reliably. It includes changes
from all and incorporates:

  - Prefix the instances of su in the fail-2eperm script with /bin/
  - Change the order of arguments so that the user name comes first
  - Change the test of the rm -rf to specify ../../../../src/rm
  - Change the created expected file to match

All this appears necessary because we are running the checks *before*
install of the new components (so we don't know if the new stuff is in
/stage1 - may be running fresh and they are not there or re-running and
they are there) and we have no idea of the versions of su, sh and maybe
other stuff that will affect the run.

Various other combinations would try to run /root/.bashrc, even when we
thought we were a new su'd user, and so gave "Permission denied"
messages. This was fixed by moving the user first in the su parameters.

Running su without the /bin/ prefix gave the problem of where is things
again (running fresh gets the host su, re-running with stuff left in
stage1 got the new su and gave error messages again).

This takes care of the root-check stuff on my host. The user tests are
still failing - will address them now.
-- 
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