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