Re: Adding entries to a directory

[Carl Fredrik Hammar]

Hi,

On Tue, Nov 17, 2009 at 09:21:18PM +0200, Sergiu Ivanov wrote:
> > > > My idea was that a unionfs *run* by root can recreate any auth object
> > > > that the client has and then authenticate with it against the unioned
> > > > directories.
> > > > 
> > > > If run by any other user then it can only recreate the intersection of
> > > > credentials between unionfs and the client.  This isn't ideal, but it
> > > > does ensure that unionfs doesn't accidentally grant the client any new
> > > > permissions by mistake.
> > > 
> > > From the theoretical point of view, there isn't really a problem,
> > > since unionfs should always grant permissions which are intersection
> > > between its permissions and the permissions of the calling client.
> > > Even if unionfs is running as root, it shouldn't give the calling
> > > client more permissions than they already have.  OTOH, bugs can bring
> > > about security problems in any case :-)
> > 
> > As explained above this assumes that the file permissions tell the
> > whole story.  The main problem with my suggestion is that it might be
> > too restrictive.  For instance, if user Alice wants to add an entry
> > to Bob's union directory.  Alice has permission to add to the unioned
> > directory because she's its owner but is not a member of the owning
> > group, Bob also has permission because he is a member of the group,
> > and others are not permitted.  The problem is that the intersection of
> > their credentials will contain neither the user nor the group required to
> > write to the directory, even thought both Alice and Bob has the necessary
> > permissions on their own.
> 
> Hm, interesting situation, it didn't occur to my mind.  However, I'd
> think that this problem is specific to any filesystem based on
> standard POSIX permission bits.  Your idea was about creating an
> alternate file access control mechanism, right?

Well, this situation isn't a problem in the current implementation, so it
isn't specific to regular permission bits.  This is because Bob would use
his group membership to add the entry on Alice behalf, which he allows
because the permission bits state that she's the owner of the directory.

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.

> > 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.

Note that this has the problem I described.  But it wouldn't if
io_restrict_auth was defined to intersect the operations allowed by two
credentials instead of the credentials themselves.  Such a definition
would be more useful IMHO, but a separate project of course.

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.

Regards,
  Fredrik