Re: Adding entries to a directory

[Carl Fredrik Hammar]

Hi,

On Wed, Nov 18, 2009 at 08:03:30PM +0200, Sergiu Ivanov wrote:
> 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
> ENOENT.

Oh, ok. It still doesn't seem right to me though.

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

Well that applies to any proxy really.  What I'm talking about
unauthenticated ports vs.  ports restricted with clients credentials.

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

It should return FS_RETRY_REAUTH when it returns a port to non-directory
nodes as well, or atleast that is how translator transitions are
currently handled in the Hurd.  (See my ``Solving firmlink problem using
io_restrict_auth mail'' for alternative inspired by this discussion)

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

Yes, but you aren't forced to do reauthentication if you return a port
that is already authenticated.  That's the problem.

Regards,
  Fredrik