[Top][All Lists]

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

Re: Adding entries to a directory

From: Sergiu Ivanov
Subject: Re: Adding entries to a directory
Date: Wed, 18 Nov 2009 00:15:16 +0200
User-agent: Mutt/1.5.20 (2009-06-14)


On Tue, Nov 17, 2009 at 10:29:40PM +0100, Carl Fredrik Hammar wrote:
> > > 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.

Aha, I see.
> 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?
> > > 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.
> 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.

It looks clear to me now.  Thanks for the detailed explanation :-)
> 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?


reply via email to

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