lkml.org 
[lkml]   [2000]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: (reiserfs) Re: NFSv4 ACLs (was: ...ACL's and reiser...)
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.529 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site