Messages in this thread | | | Date | Thu, 1 Jul 1999 18:09:18 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [security]: kernel ioctl()'s [3] |
| |
On Thu, 1 Jul 1999, Alan Cox wrote:
> > 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/
| |