On Sun, Jul 19, 2009 at 4:07 PM, Marc Balmer<marc%msys.ch@localhost> wrote:
Am 19.07.2009 um 14:58 schrieb Elad Efrat:
On Sun, Jul 19, 2009 at 3:49 PM, YAMAMOTO Takashi<yamt%mwd.biglobe.ne.jp@localhost
>
wrote:
hi,
On Sun, Jul 19, 2009 at 10:34 AM, YAMAMOTO
Takashi<yamt%mwd.biglobe.ne.jp@localhost> wrote:
can you explain what's the point to call kauth when fs_decision
is
already non-0?
i don't think it's a good idea to let kauth allow operations
which
have already been rejected by the filesystem itself.
I think it's a very good idea, because then kauth(9) can
implement MACs.
can you explain how it's required for MAC? it isn't clear to me.
Consider a file owned by yamt:yamt (say, 1000:1000) with permissions
0600. Let's say root is trying to access that file. Because root has
euid 0, and the file has uid 1000, the file-system will deny access
due to uid mismatch. However, once kauth(9) gets a chance to flip
the
huh? since when can root not access a file with 0600 permission of
any
user?
are you sure you are running unix there?
I am running unix, but I am also running it in 2009, and not 1979.
The file-system should have no knowledge of "root" (or "securelevel"
for that matter). All it knows is that (a) it has its internal way of
access controls, usually uid-based, and that (b) it should let
kauth(9) have the final word. The latter can be (and is) used to
implement root, to always allow access to euid 0, but that number
(zero) is an implementation detail.
Nothing prevents me from deciding that uid 1337 is root if I want to,
or that there are 6 securelevels, or that there are capabilities I can
associate with processes, etc.