[Toybox] [Aboriginal] aboriginal linux

[Rich Felker]

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

 1411939522.0