bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Readable files: a Unix philosophy question for gurus


From: Aharon Robbins
Subject: Re: Readable files: a Unix philosophy question for gurus
Date: Mon, 10 Feb 2003 14:05:11 +0200

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 <address@hidden>
> To: address@hidden
> CC: address@hidden, address@hidden, address@hidden,
>    address@hidden, address@hidden, address@hidden,
>    address@hidden
> Subject: Re: Readable files: a Unix philosophy question for gurus
>
> > From: Jim Meyering <address@hidden>
> > 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]