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
