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

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

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

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