Messages in this thread | | | Subject | Re: (reiserfs) Re: NFSv4 ACLs (was: ...ACL's and reiser...) | From | James Antill <> | Date | 07 Aug 2000 16:52:25 -0400 |
| |
Xuan Baldauf <xuan--reiserfs@baldauf.org> writes:
> James Antill wrote: > > > Xuan Baldauf <xuan--reiserfs@baldauf.org> writes: > > > > > Linda Walsh wrote: > > > > > > > [...] > > > > What would you see the behavior being if process 'x' is chroot'ed > > > > to directory 'y' and you blocked access to a directory above it's root? > > > > Would the access checks still be done to the root of the filesystem or > > > > just the 'root' of the process? > > > > > > > > -linda > > > > > > > > -- > > > > Linda A Walsh | Trust Technology, Core Linux, SGI > > > > law@sgi.com | Voice: (650) 933-5338 > > > > > > How is it done now? If some process chroots to /dir1/dir2, and tries to access > > > /dir1/dir2/file, does the access succeed or fail after a "chmod 000 /dir1"? Is the > > > current behaviour not incorrect, too? > > > > I think you are misunderstanding. > > If it chdir()'s then access _should_ fail[1]. > > If it is chroot()'d then it wouldn't be able to open() via. that > > scheme anyway. > > > > [1] Logically, I haven't checked this but I doubt there is any magic > > there if dirname() == $cwd. > > If I understood Linda correctly, there is magic, because (the access to) the resulting > "." is resolved at chdir time, not at access time. Therefore access should succeed even > when chdir()ing, not chrooting(). And also according to Linda, open() could succeed, > because (the access to) the new "/" is resolved at chroot time (and not access time), > too. So who's right? (I agree that there is a misunderstanding, but I still cannot see > who is wrong with what opinion. :-))
% mkdir /tmp/abcd % mkdir /tmp/abcd/xyz % touch /tmp/abcd/xyz/foo % ls /tmp/abcd/xyz/foo /tmp/abcd/xyz/foo % cd /tmp/abcd/xyz % chmod 0 /tmp/abcd % ls /tmp/abcd/xyz/foo /bin/ls: /tmp/abcd/xyz: Permission denied % ls foo foo
Ie. the kernel still resolves _at access time_ "/tmp/abcd/xyz", _even though_ it is also ".".
> > ...but apart from all these it's slower it's not arguments, as a sys > > admin I _know_ that for permissions on a name[2] I have to check the file > > itself and the previous directory[3], if anything changed that simple > > permission model to a complicated one where I have to check _every_ > > dir back to the root then it's time to get out vi and diff IMO[4]. > > > > [2] A name == a vfs object, be it a file, a socket, a dir, etc. > > > > [3] Not counting hard links > > You know that checking the previous directory also implies checking the parent of this > directory, and this directories parent.? I agree that the permission model is simple, > but you see that it can become quite complicated to resolve accessibility to an fs > object from a particular user. (Because accessibility does and does not depend on the > accessibility of the parent, depening on how you try to access.) Maybe ACLs will give > you the possibility to instant-resolve every ACL to every fs object "ls" is listing. (So > you won't have to check reachability through the parents, because this reachability is > already calculated when printing ACLs..)
Assuming you have access to the dir (Ie. you are doing open("./abcd", ... ) then you don't need to go any further back[1]. Also when I do the "chmod 700 /tmp/abcd" I _know_ (assuming there aren't any acls on it) that xyz and xyz/foo are unreachable from other users, what I don't want (and what I thought some people were advocating) is for there to be a dynamic acl on tmp that lets a group/person go inside "/tmp/abcd".
> > [4] From what Ted's said this isn't going to happen, so i'm happy, I'm > > just giving you another reason why Ted is right :). > > Currently, I'm in favour of Ted's "I want the question wether to allow or deny access > answered immediately."-attitude. I just do not think that this inevitably means that we > need to end up with static ACLs and their disadvantages. (Maybe my opinion changes when > Hans "unveils" his fast, yet inheriting ACL approach.)
If you mean that doing 'chacl -R "user bob: +rx" /tmp/' would do something clever inside the fs so that only one acl was changed, then fine. However if you mean that 'chacl "user bob: +rx" /tmp/' would be dynamically inherited by "/tmp/abcd" then I think that is a Really Bad Idea(tm)[2].
[1] You could say you never do and that when you do "/tmp/abcd/xyz/foo" you just have to go forwards through the whole path.
[2] If I'm really off base here tell me, but I can't think why you'd want to base a file system feature around "chmod/chacl -R" ... esp. as the idea of reference counting acls and just linking to them would make this operation pretty fast and space efficient anyway IMO.
-- James Antill -- james@and.org "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |