About the only way to do this completely reliably (at least for read and write) is for test to actually try and open the file. Exec is another story, unfortunately.
> Date: Sun, 9 Feb 2003 20:45:08 -0800 (PST) > From: Paul Eggert <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: Re: Readable files: a Unix philosophy question for gurus > > > From: Jim Meyering <[EMAIL PROTECTED]> > > Date: Sun, 09 Feb 2003 10:14:32 +0100 > > > > There is indeed a problem with the `test' in the coreutils -- > > and with the nearly identical built-in provided by bash. > > I've just changed the one in coreutils to use euidaccess > > (either the one in libc, or the supplied replacement). > > That solves the problem only in the (albeit common) case > > in which effective and actual UID and GID are identical. > > As I understand it, the euidaccess replacement attempts to guess what > 'access' would return if the real uid and gid were temporarily set to > the effective uid and gid. This guess can be wrong for many reasons > (e.g., ACLs, read-only filesystems, etc.), andit would be a > maintenance hassle to improve the guess's quality on all systems. > > Wouldn't it be easier to set the real uid and gid temporarily to the > effective uid and gid, then invoke 'access', and then set the real uid > and gid back? This method will handle all that nonportable ACL > etc. stuff automatically. The method won't work on all ancient hosts, > but it'll work on all modern ones and we can fall back on the current > euidaccess method if we're on an ancient host. Also, I suppose this > method would be a pain if you need euidaccess to be reentrant, but > test(1) shouldn't need that. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
