Re: Adding entries to a directory

[Carl Fredrik Hammar]

Hi,

On Wed, Nov 18, 2009 at 12:15:16AM +0200, Sergiu Ivanov wrote:
> On Tue, Nov 17, 2009 at 10:29:40PM +0100, Carl Fredrik Hammar wrote:
> >
> > I don't so much want to create a new file access mechanism, as I
> > want to rely on the unioned directories own access mechanism, and let
> > them decide whether to allow Alice to add an entry.  As it is now,
> > unionfs implements an access policy which it *assumes* is the same as
> > the unioned directories.
> 
> Aha, so you are talking about removing access policy implementation
> from unionfs and making unionfs check with the directory whether a
> certain user is allowed to add entries to it?

Yes.

> > > > I just remembered that io_restrict_auth is described to do the exactly
> > > > what we want.  However, it seems that in practice translators just make
> > > > an intersection of the credentials, so it has the same problem.  :-(
> > > 
> > > Could you please give an example of how would you suggest to use
> > > io_restrict_auth?  The fact is that unionfs, for instance (but I
> > > believe other translator do similarly) does use io_restrict_auth, but
> > > it indeed uses it to do the intersection.  (This is most probably what
> > > you are talking about; I'm just restating it in more detail to avoid
> > > ambiguity.)
> > 
> > 1. Alice opens unionfs directory
> > 2. unionfs opens unioned directories using Bob's credentials
> > 3. unionfs restricts auth of directories to Alice's credentials
> > 4. Alice adds entry
> > 5, unionfs adds entry to whichever directory gets new entries
> > 
> > Notice how unionfs doesn't need to check whether Alice is permitted to
> > add the entry.  It simply relies on that the unioned directory does it.
> 
> I see.  The check is ``done'' by the directory, and unionfs simply
> tries adding the entry and stops whenever a directory accepts the
> entry or when it finished traversing the list of directories.

I imagined that you'd only try to add an entry to one of the unioned
directories, otherwise it is hard to predict where the entry will
eventually be placed.

> > Also I looked up how unionfs uses io_restrict_auth, and I'm a bit
> > confused.  It seems it only restricts normal files with the client's
> > credentials.  I can't tell whether it then proxies the file or returns
> > it, but if it is returned then it should be reauthenticated by the client,
> > and then it is best to return a completely unauthenticated port, either by
> > not authenticating it at all, or restricting auth with empty credentials.
> 
> unionfs does not proxy ports to normal files.  The necessity of
> reauthentication arises from the fact that the credentials associated
> with the port unionfs returns may not be the same as those of the
> client, but only a subset of them, right?

Yes, but I also think that it should be possible to forward a not yet
authenticated port without risking privilege escalation.  That is, if you
return an authenticated port, a proxy might think it is safe to return the
port to its own client, which would leak the proxies access to its client.

I'm not entirely sure if this isn't a rule I just made up myself, but
it seems natural to assume that a port returned with FS_RETRY_REAUTH
should be unauthenticated.

Regards,
  Fredrik