On 7/31/06, go moko <[EMAIL PROTECTED]> wrote:
I create a second user, lfs. > su - lfs > test -r /proc/self/fd/0 > echo $? returns 1 But > chmod o+rw /dev/tty1 (as root) > su - lfs > test -r /proc/self/fd/0 > echo $? returns 0 On a different tty, same problem: until I give rights to clfs on /dev/tty2, it returns 1. It seems that the login reduces the rights on each tty before the connection.
This is potentially very important for all the LFS projects considering that we tell everyone to build as unprivelaged in BLFS. If you ever rebuild or update bash, there's a good chance you'll fail this feature test. I noticed that /dev/ttyX was getting changed to 600 permissions owned by my user a few weeks ago, but never knew how or why. It seems from what you both have said, login changes the permissions, but su doesn't for obvious reasons. I don't have access to a system to toy with, but it seems like "bash_cv_dev_fd=yes" is probably the best workaround. I don't think this is really an issue with our build method. The feature test seems to be making assumptions about the target environment that can't be accurately tested for. It should probably be "test -e /dev/fd/3" since the test is whether it is _available_, not necessarily whether it's readable by the current user. Look at the message in the macro. Someone should mention this upstream to atleast see what they have to say. -- Dan _______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
