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


James Antill wrote:

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

Yes. If you tell the kernel "walk from root down", it should do. I think we talked at cross
purposes. You told me strcmp(dirname(),$cwd)==0 and I understood strcmp(dirname(),".")==0;
behaviour should be quite similar, shouldn't it? (But the former comes from outside a "chmod
000"-barrier, the latter from inside in our cases.) As I already said, I feel

% ls /tmp/abcd/xyz/foo
/bin/ls: /tmp/abcd/xyz: Permission denied
% ls foo
foo

to be a contradiction, but this is subjective. :o)

So: the kernel does not do your magic (comparing dirname() with $cwd), but it does my magic
(using the old resolved rights for "." rather than the current one.)

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

I only advocate this if after your "chmod 700 /tmp/abcd" is a "chacl -R user bob +rwx /tmp",
but this should be legal, I think.

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

Without "-R", there shouldn't be any dynamic inheritance.

>
>
> [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"

Because I do not like to wait (and probably many other people, too). And because people tend
to use directories to group similar things together. Often, similar things should have similar
access rights. If a user thinks "these files should be rw-accessible by joe and sue, and
r-accessible by bob, and not accessible by anybody else", the filesystem should implement it
that way. Likewise an ISP could implement those rules: "all files below /data/webexport should
be readable by httpd, and all files below that directory should be writeable by their
respective owners, and no one else should be able to access those files". Now imagine the ISP
wants to give a web-site maintainer (bob) rw-rights to everything below "/data/webexport".
"chacl -R user bob +rw /data/webexport" is all which needs to be done, and it is executed
immediately. The primary reason is: speed and "object-orientedness". You see your directory
(including everything below it) as an object, and this object should have certain properties.

Also, a certain flavour of ACLs could make it possible to have a dir "/dir1" accessible by
everyone and "/dir/file" accessible by "everyone the parent (/dir) grants and sue, too". If
you downgrade the access to /dir to "students only", the access to "/dir/file" still can be
"everyone the parent (/dir) grants and sue, too". With non-dynamic, always effective ACLs, you
could not apply logical operations to the rights of the parent, further fine-graining the
access control as needed. With alwayss effective ACLs, further fine-graining should be fairly
difficult, because you could not decide wether an ACE is due to the parent (or any other
imported ACL object) or wether it is due to the process of fine-graining.

Maybe it is like the difference of a database-table and a spreadsheet-table. If you change the
database-data in a cell, nothing else changes. But if you change some spreadsheet-data, many
values in many cells may differ. You could, of course, change many database-cells at once, but
it's not the same as changing one spreadsheet-cell and seeing how other cells change too
(because they depend directly or indirectly) on that cell.

> ... esp. as
> the idea of reference counting acls and just linking to them would
> make this operation pretty fast and space efficient anyway IMO.

I can agree with space efficient, but I have doubts with "fast". As there is no hard disk you
cannot make full, there would be no "chacl -R" operation which you could not make need too
much time.

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

Xuân. :o)



-
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.062 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site