Hi, 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: > > > > I don't so much want to create a new file access mechanism, as I > > want to rely on the unioned directories own access mechanism, and let > > them decide whether to allow Alice to add an entry. As it is now, > > unionfs implements an access policy which it *assumes* is the same as > > the unioned directories. > > Aha, so you are talking about removing access policy implementation > from unionfs and making unionfs check with the directory whether a > certain user is allowed to add entries to it?
Yes. > > > > 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 > > > ambiguity.) > > > > 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. > > Also I looked up how unionfs uses io_restrict_auth, and I'm a bit > > confused. It seems it only restricts normal files with the client's > > credentials. I can't tell whether it then proxies the file or returns > > it, but if it is returned then it should be reauthenticated by the client, > > and then it is best to return a completely unauthenticated port, either by > > not authenticating it at all, or restricting auth with empty credentials. > > 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. 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. Regards, Fredrik
