[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: Tue, 17 Nov 2009 21:21:18 +0200
User-agent: Mutt/1.5.20 (2009-06-14)


On Tue, Nov 17, 2009 at 07:20:03PM +0100, Carl Fredrik Hammar wrote:
> On Tue, Nov 17, 2009 at 06:49:24PM +0200, Sergiu Ivanov wrote:
> > On Tue, Nov 17, 2009 at 01:15:59PM +0100, Carl Fredrik Hammar wrote:
> No, I think you're confusing authentication and access control.
> Authentication is the method used to establish the identity of a client,
> i.e. which user(s) and groups it is run by.  Access control is deciding
> which permissions the client has, typically based on which identity
> it has.

Yes, right!  I felt I was using the word ``authentication'' wrongly
:-( Thank you for reminding me the explanation.
> Authentication must be the same throughout the system to be useful.
> Access control is all up to the individual servers, and can be different
> throughout the system.  It is easy to imagine new types of access control,
> e.g. owner permissions for several users, or even a time lock that denies
> access after a certain date.  There are many possibilities which I think
> we should leave open.

Yeah, that's right.
> > > (But I might be missing something, perhaps POSIX says that regular file
> > > permissions should always be correct or something.)
> > 
> > Hm, why could POSIX say that regular file permissions may *not* be
> > correct? :-) I may be missing something, but it's hard for me to
> > imagine that POSIX file permissions were introduced with the thought
> > in mind that they may be wrong.
> ``Correct'' wasn't really the right word, ``incomplete'' is more
> appropriate.  It seems that file permissions bits must always be present
> in some form, but that additional file access permissions may further
> restrict permissions:
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_04
> If this is the case then unionfs may inadvertently grant a permission
> that the unioned directory would've denied due to such an additional 
> mechanism.

Hm, I see.  I guess can understand you correctly now.
> > > 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?
> 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

reply via email to

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