Updated buildscripts (v2.2.8)

Bill's LFS Login lfsbill at wlmcs.com
Sun Apr 20 09:39:18 PDT 2003


Hi Erik!

First, a note. After I sent this last night, I realized that the changes
I mentioned that didn't work in the fail-2eperm when running the
root-check tests in chapter 5 weren't from EJ, but from RH (adjusting
the names=). It may work yet too - may be affected by what you have
uncovered here. Apologies for any confusion.

On Sun, 20 Apr 2003, Erik-Jan wrote:

> Bill's LFS Login wrote:
> ><snip>

> Hi Bill,
>
> I've been working on the coreutils make check as well, but the
> fail-2eperm-test only gives me problems in coreutils versions up to
> 4.5.9. In 4.5.10, the fail-2eperm-test has been changed and it works ok
> for me now.
> (small quick-fix for 4.5.9: edit tests/rm/fail-2eperm, find the line
> starting with "su -c" and change that to "su --shell=/bin/sh -c"  It now
> definately uses a valid shell)

Running chrooted from lfsbill to root.
Without the extra '-', it would give me messages about permission denied
when the su was done. So I guess without the '-', it was getting su from
stage1 (it's in /stage1/bin then) and bash/sh from the host env (since
these haven't been made in /stage1 yet yet). Adding the '-' (or other
possible things) fixed that.

My $PATH at the time is (ignore wrapping)

  /stage1/bin:/stage1/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:
  /root/bin:/usr/X11R6/bin:/usr/src/qt-x11-free-3.0.5/bin

> The sed you send suggests there is something wrong with PATH, while
> doing the tests. Can you do this for me to make sure?
> untar a fresh coreutils and cd into it
> do the usual ./configure --prefix=/stage1 && make LDFLAGS="-s"

Keep in mind that my host is an LFS from 2002-10-29 with some upgrades.
Installing Ryan's stuff: HJL binutils, gcc 3.2.2, glibc 2.3.2.

As root (my environment is as in Ryan's build-ch5* script) ran:

  CFLAGS="-O2 -pipe" ./configure --prefix=/stage1
  make LDFLAGS="-s"

> enter the src-dir. Now we can do the test manually:

cd tests/rm

> mkdir a
> chmod 1777 a
> touch a/b
> su --shell=/bin/sh -c 'rm -rf a' username
>  ** username is any user on your system, different from the (root?)user

Running

  su --shell=/bin/sh -c 'rm -rf a' lfsbill

resulted in

  /bin/bash: --shell=/bin/sh: unrecognized option
  Usage:  /bin/bash [GNU long option] [option] ...

My env shows BASH_VER=2.05b, but see more below.

> that did the configure and make. So on your system it will be ehhh bill?
> :))
> This should give you the output you got, with the "unlink" and
> "Directory not empty"-things

As you can see ...

> Now try:
> su --shell=/bin/sh -c './rm -rf a' username

Same results as the first test.

Found a questionable thing here:

   .../tests/rm# su --version
   GNU bash, version 2.05a.0(1)-release (i686-pc-linux-gnu)
   Copyright 2001 Free Software Foundation, Inc.

but note the following

   .../tests/rm# /stage1/bin/su --version
   su (coreutils) 5.0
   Written by David MacKenzie.

   Copyright (C) 2003 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There
   is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
   PURPOSE.

So, I'm doing the su test again with /stage1/bin prefix:

   .../tests/rm# /stage1/bin/su --shell=/bin/sh -c 'rm -rf a' lfsbill

gives

   rm: cannot remove `a': Permission denied  # AHA! (me, not the cmd)

and

   .../tests/rm# /stage1/bin/su --shell=/bin/sh -c './rm -rf a' lfsbill

gives

   sh: ./rm: No such file or directory

BINGO! All that prompted a test using the coreutils orig code (sort of):

   .../tests/rm# su -c 'echo $PATH;rm -rf a' lfsbill

gave

   /sbin:/bin:/usr/sbin:/usr/bin

Doing

   .../tests/rm# /stage1/bin/su -c 'echo $PATH;rm -rf a' lfsbill

gave (ignore wrapping)

   bash: /root/.bashrc: Permission denied
   /stage1/bin:/stage1/sbin:/sbin:/usr/sbin:/bin:/usr/bin:
   /usr/local/bin:/root/bin:/usr/X11R6/bin:
   /usr/src/qt-x11-free-3.0.5/bin
   rm: cannot remove `a': Permission denied

So I double checked $PATH (and checked export also) and it is as shown.

So I ran

   ...tests/rm# /stage1/bin/su --shell=/bin/sh lfsbill -c \
   'echo $PATH;rm -rf a'

and got (ignore wrapping)

   /stage1/bin:/stage1/sbin:/sbin:/usr/sbin:/bin:/usr/bin:
   /usr/local/bin:/root/bin:/usr/X11R6/bin:/usr/src/qt-x11-free-3.0.5/bin
   rm: cannot remove `a': Permission denied

So, it is some kind of PATH anomoly. But why?

> It now uses the newly built rm, and it should give the expected "./rm:
> cannot remove `a/b': Operation not permitted". This is the way the full
> fail-2eperm-test should work.
> Does your system do this as well?

As you see, no. The './rm' does not exist in the tests/rm directory. But
other than that, you nailed the PATH issue. My question is: can we
safely replace my seds of the su with one that changes su to
/stage1/bin/su or something better, like your --shell=... thing. It
looks like we might need a combination of both to work?

Also, because I was CnPing a few lines at a time, I wonder if soemthing
in my env is scrogged (doesn't affect the original problem because I was
running Ryan's scripts when it first appeared). I'll try the scripted
one again with your patches, unless you holler that we need a change
based on your analysis of what I've shown here.

> I've attached a patch that I've used to test with coreutils-4.5.9,
> 4.5.10, 4.5.12 and 5.0, and fileutils 4.1 and 4.11, and all tests went
> OK. I've used the CANDIDATE_TMP_DIR-thing as well, only I exported it in
> the build-init-script; makes it easier to change when building on
> another pc.

Yep. I didn't do that initially because I wanted it to show close to the
code it affected until more knowledgeable folks saw, tested and approved
it as a Good Thing (TM).

> <snip>

> Erik-Jan

I'm going to give those patches a try. As noted above, the fix that
didn't work in check-root wasn't yours, but RH's (names= fix) and it may
also be affected by what you have now led me to. I had not tested yours
yet. My misstatement was due to that disease sweeping Australia and now
invading the U.S., RBF (Ryan's Brain Fart  :)

-- 
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