On Mon, 31 Jul 2006 22:47:09 -0400 Bryan Kadzban
<[EMAIL PROTECTED]> wrote:
> Ken Moffat wrote:
> > Hopefully, somebody has test results ?
>
> I think this is a known issue when using package users, but with bash,
> not glibc. The bash testsuite fails a couple tests because the current
> TTY is not owned by the user running the tests (because when using that
> hint, chapter 6 su's from root to each package user when installing each
> package; root owns the TTY).
>
> Anyway, there's a note in the package-user hint about this, in the
> "known issues with LFS packages" section on bash -- but it only affects
> bash's tests, not its configuration.
Actually it does affect the configure, too. And it has always done so.
I've had a note about this in my .project for bash ever since I started
with package users and I could swear I had it in the hint at some point,
but it's not in the current version and I don't have copies of the older
hints to find out if it was there and when it disappeared.
In bash 2.x the problem affected /dev/std* and /dev/fd/*. The tests that
failed were of the type
test -r /dev/stdin
and they fail, because these "devices" are just symlinks that end up
pointing to the (pseudo) terminal you're working in and since su
doesn't change ownership of the terminal device the
access fails with a Permission Denied error.
In bash 3.x the tests have been improved like this
test -r /dev/stdin </dev/null
Note the </dev/null redirection which makes the file descriptor for
stdin refer to /dev/null instead of the terminal. As /dev/null is
world-readable and world-writable, the check goes through.
However the test for /dev/fd/* still fails because of the following part
# check for systems like FreeBSD 5 that only provide /dev/fd/[012]
exec 3<&0
if test -r /dev/fd/3; then
bash_cv_dev_fd=standard
else
bash_cv_dev_fd=absent
fi
exec 3<&-
The exec 3<&0 creates a copy of file descriptor 0 with number 3 and then
tests read access to the new file descriptor via the special device.
Because fd 0 is stdin we have the problem again that was described above.
The check should have used /dev/null like this instead
exec 3</dev/null
which would work properly. I suggest someone file a bug report about this
on the bash mailing list.
About the difference it all makes:
1. For both /dev/fd/* and /dev/std* bash offers 2 possible configurations:
direct access and emulation.
2. When configured for direct access, redirecting to the respective
devices will fail when su'd to a non-root user (assuming that the file
descriptor in question points to a terminal owned by another user).
3. When configured for emulation, redirection will work even when su'd,
but you're not getting "the real thing". I actually used to prefer this
mode, because it makes redirections always work as intended, regardless of
whether you're su'd or not. Now I'm using zsh so I don't care anymore.
4. Bash chooses between emulation and direct access at configure time
based on tests that seem to change over time and give inconsistent
results (e.g. currently bash gives you emulation for /dev/fd but direct
access to /dev/std* when configured by a su'd user).
5. The most predictable way to deal with this is to decide if you
want emulation or direct access and to manually add either
#define HAVE_DEV_FD 1
#define DEV_FD_PREFIX "/dev/fd"
#define HAVE_DEV_STDIN 1
or
#undef HAVE_DEV_FD
#undef DEV_FD_PREFIX
#undef HAVE_DEV_STDIN
at the end of config.h after running ./configure
6. Another way to deal with this would be to run configure like this:
./configure .... </dev/null
7. And of course, chowning the terminal device in question before
running configure will also work.
8. 6 and 7 also work for make check.
9. Yes, I'll put it into the next version of the hint.
MSB
--
The average woman would rather have beauty than brains,
because the average man can see better than he can think.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
