On Sun, Sep 28, 2014 at 02:05:02PM -0700, Isaac Dunham wrote: > On Sun, Sep 28, 2014 at 11:36:11AM -0500, Rob Landley wrote: > > Redirected to the toybox list, where I have a pending message to reply > > to on this topic already... > > > > > Long ago I developed a strong dislike for the library emulating features > > > when GNU's glibc emulated aio by helpfully making my program > > > multi-threaded and hijacking signals. > > > > You think that's bad, dalias decided that implementing AT_EACCESS > > required spawning a new process for every system call. (setfsuid() > > exists, thanks to the samba guys, but apparently doesn't apply here. No > > idea why.) > > man 2 setfsuid says that > > The system call setfsuid() changes the value of the caller's filesystem > user ID--the user ID that the Linux kernel uses to check for all > accesses to the filesystem. Normally, the value of the filesystem user > ID will shadow the value of the effective user ID. In fact, whenever > the effective user ID is changed, the filesystem user ID will also be > changed to the new value of the effective user ID. > > Explicit calls to setfsuid() and setfsgid(2) are usually used only by > programs such as the Linux NFS server that need to change what user and > group ID is used for file access without a corresponding change in the > real and effective user and group IDs. > > Reading the last sentence of the first paragraph, it would seem to be > implied that AT_EACCESS is actually the default behavior... > which I somehow find surprising.
In general, all filesystem access functions use the _effective_ (or, on Linux, if it's been changed, the _filesystem_) uid/gid to determine whether the process has access to a file. However, the access/faccessat functions are special and default to using the _real_ uid/gid. The historical _intent_ was that suid-root programs can use access() to determine whether the invoking user would be allowed to access a file before actually performing the operation to access it. However, such usage has a fundamental TOCTOU race which is always a vulnerability. So, essentially, the access function is useless for its original designed purpose. > Anyhow, an alternate proposal for how to handle rm -rf: > Try deleting files, and handle errors by the chmod path if errno == EPERM. > > Is there a reason not to do this? This is the right way to do it. I just wrote to the musl list (and CC'd toybox/landley) with an outline of how to do this that handles (I think) all of the possible file/dir-replacement races. Rich _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
