Re: Adding entries to a directory

[Carl Fredrik Hammar]

Hi,

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:
> > On Tue, Nov 17, 2009 at 11:57:46AM +0200, Sergiu Ivanov wrote:
> > > On Mon, Nov 09, 2009 at 02:58:12PM +0100, Carl Fredrik Hammar wrote:
> > > > On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafBuddenhagen@gmx.net wrote:
> > > > > 
> > > > > > Well, obviously, O_READ permission on a directory is sufficient to
> > > > > > create files in it.
> > 
> > > > How to properly verify whether a client has this access in
> > > > a proxy such as unionfs is an interesting question.
> > > > If run by root it could recreate whatever auth object
> > > > the client is using, but its harder for a normal user.
> > > 
> > > Generally, unionfs checks permissions whenever it is asked to carry
> > > out some operation.  Similarly, when it is asked to create a new entry
> > > under a directory, it first checks the user's permissions.
> > 
> > Ah, yes.  That's what I thought.  Perhaps I should've explained what I
> > meant by ``properly'', which I left out in this little side note.
> > 
> > The problem with relying on file permissions is that it is only one
> > of several possible ways to specify permissions.  For instance, ACLs
> > (Access Control List) can offer a more fine grained control, where
> > permissions can be specified for individual users.
> > 
> > Now only regular file permissions are currently implemented by filesystems
> > in the Hurd, but it would be nice to have the possibility to implement
> > such alternatives in the future.  To ensure this we shouldn't rely on
> > file permissions being correct.
> 
> I see.  However, if I understand you correctly, you are talking about
> a totally different implementation of filesystem authentication
> mechanism.  In case such mechanism is ever implemented, I believe that
> the permissions check in unionfs can be pretty easily adapted to the
> new way: unionfs relies heavily on libfshelp, and the corresponding
> permission check functions could be modified to work differently.

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.

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.

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

> > > Although I fail to realize how unionfs would help root to recreate any
> > > auth object used by a client, I'd believe that root could recreate any
> > > auth object without the aid of unionfs, too :-)
> > 
> > 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.

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

But this is fixable, and I can't help to think that io_restrict auth
was created for just this purpose...

Regards,
  Fredrik