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...)
Hans Reiser wrote:
>
> There is a completely different way of implementing full inheritance that is
> efficient, and defaults to the same old behavior where it is unused.
>
> To minimize unnecessary flamage, I'll describe it only after
> I can assign a programmer to work on it, though it is not a very deep
> or profound solution.
>
> Hans
----
You realize that by implementing full inheritance other than by
the normal method of "ch<mod, own, acl, attr, etc> -R", you are breaking the
way the existing security policy works -- namely access checks, as Ted mentioned,
are done based on each pathname component given in an 'open' call -- which is
not the same as doing it from the '/root' of the file system.

You might want to give alot of thought to this before you implement
a security access-check method inconsistent with current behavior.

Ideally, if user's wanted such functionality, it would be decided
on a 'per-system' basis, not a 'per-filesystem' basis. So say, either at
kernel-build time, the user could choose to use 'resolve only from root'
or 'allow relative pathname resolution' for access checking.

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

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