> > There is what I would consider to be a minor logic error in the handling
> > of immutable in ext2's code.
>
> Im not so sure
>
> > capability, there is no reason user "fred" shouldn't be given this
> > capability so he can manage immutable/append only flag on his _own files_.
>
> But the immutability affects root it seems
Chris, Alan - there is a clean solution for that. And I'm going to ask Ted
and Stephen for such thing. The problem being: we don't support full
immutable/append-only semantics. Original implementation has a neat
detail - there are *two* Immutable flags: user and system. VFS looks for
UF_IMMUTABLE|SF_IMMUTABLE - it doesn't care which one is set. *But*
UF_IMMUTABLE acts as any normal permissions bit. It can be set/reset by
owner and by root (OK, by the process with appropriate capability).
SF_IMMUTABLE can be set only by root and can't be reset if securelevel is
positive. That way user has functionality of Immutable and root can get
the stronger variant of the same thing - one that can't be reset by file
owner and can't be reset even by root without taking the system into
single-user. The same applies to append-only and nounlink. UFS has enough
bits for that. What about ext2 (and ext3, for that matter)? I would turn
old bits into system ones and add user bits. That way we would have it
backwards-compatible. IOW, we need 2 more bits, ideally 4 (nounlink). Is
it possible? It solves the problem with privileges - UF_IMMUTABLE acts as
any other flag and SF_IMMUTABLE obviously requires root.
I'm doing that in chflags patch for UFS and adding such support
for ext{2,3} would be nice (sorry for delay with chflags - I didn't expect
that synchronizing/submitting SMP stuff will be needed that soon).
-
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/