On Sun, 25 Jun 2000, Linda Walsh wrote:
> If I understood Andi, securelevel isn't currently implemented?
> If that is so, maybe the current bits should be allowed to normal users and
> the "sec_immutable" and "sec_append_only" would be allocated in the future
> should secure level come back into existance?
We had securelevel in 2.0, and it's replaced by cap_bset in 2.2. The 2.2
capability set wasn't sufficient to fully replicate securelevel. I've
fixed that for 2.4 [1]
So a mechanism to prevent even root from messing with
append-only/immutable files _is_ in place [2]
You can't arbitrarily allow users to set append-only or immutable bits as
they currently stand. Programs running as root expect unlink(),
chmod() etc. to work on all files. Allowing users to "surprise" privileged
programs in yet another way is a no-no.
As Al Viro said, if you want user immutable, the correct way to do it is a
new type of immutable which is ignored by root.
Cheers
Chris
[1] We had to add CAP_MKNOD
[2] Insert here: usual disclaimers about having to disable raw i/o, raw
memory access, raw disk access etc. See CAP_RAW_IO, CAP_MODULE
-
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/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:07 EST