--- This makes alot of sense.I would guess (?) that an accidental 'rm -fr' by root wouldn't remove normal 'immutable' files -- but that they would still be required to remove the immutable bit first? If not, root couldn't use user-level immutable w/o being afraid that they or a root level program wouldn't accidently remove the file same as today...
> Same goes for append-only. That makes sense - there are > times when you want to protect against your own screwups and be able to > do/undo that without su. If we add that we may restore the securelevel-type > scheme for strong variants of these (useful for enforced security) and let > users have the weaker variant.
--- 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?In order to protect against programs including code to 'override' user-immutable, I could see 'chattr' being enhanced to be a security-enforcing program (like passwd) that would allow users (except root) to only change bits on their own files but would also be 'suid' so that setting +i and +a bits is still a privileged operation that can't be simply overridden by user-level programs. When and if the secure-level feature is added back in, the new bit flags in the same program could be "+/-I" and "+/-A".
Just a thought... -l
-- 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/