[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 20:03:30 +0200
User-agent: Mutt/1.5.20 (2009-06-14)


On Wed, Nov 18, 2009 at 10:21:13AM +0100, Carl Fredrik Hammar wrote:
> 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:
> > >
> > > 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.

This is how unionfs does the things now: it tries to look up the
filename with O_CREAT under every unioned directory and stops at the
first directory which returns no error or an error different from
> > 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.

Hm, interesting.  Are you talking about that type of proxies which
have broader permissions than their clients?  In this case I'd say it
is the proxy's responsibility to think of security and give out to the
clients unauthenticated ports.

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

The comment to FS_RETRY_REAUTH in hurd/hurd_types.h says ``Retry after
reauthenticating retry port''.  However, the only moment when unionfs
(and libnetfs, IIRC) returns FS_RETRY_REAUTH is when the ``..''
filename is requested.  In this case the shadow_root_parent from the
peropen structure is returned as the retry port, but I cannot tell
whether it is unauthenticated.  So, I'd rather say that it is okay to
assume that the port returned with FS_RETRY_REAUTH is unauthenticated,
but it might not be true.  Actually, it doesn't really matter, since
you are anyway bound to do reauthentication.


reply via email to

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