From: Herbert P÷tzl (herbert_at_13thfloor.at)
Date: Mon 28 Jul 2003 - 01:23:33 BST
So let the debate beginn *G*
(I really enjoy a good discussion anyway)
>On Sun, 27 Jul 2003 22:26, Herbert P÷tzl wrote:
>> if you provide substantial arguments, why we need
>> this ;-) I will support you on this crusade ...
>> > [...] a more generic solution may end up solving problems
>> > that you didn't think of originally.
so you think that the ILI bit *is* a *more generic*
solution and that it solves problems, we do not think
of? which problems would that be? and why do you
think they are not solvable by my suggestion?
a short retrospection:
- immutable + link in (context != 0,1) gives
unlinkability (if nlinks > 1)
- on transition from nlinks==2 to nlinks==1
immutable bit is cleared.
>>> This breaks the normal immutable semantics.
>>> On the other hand, this would be fine if it was a
>>> configurable behaviour.
well, the normal immutable semantics are not very
important for vserver user anyway, but they would
not be broken, except for files owned by context 0/1
and, this could be easily hidden from the vserver ...
>>> You will still need the split immutability macros,
>>> so all it saves you is one bit per inode.
and a lot of user space tool rewriting, which
in my opinion is a big nono for vserver users
anyway ... either you change all the tools for
all filesystem types supporting immutable flags
or you add some new tools like showattr + setattr
to modify the additional bit(s) ...
>> it could either be limited to the context environment
>> (as suggested, which would not break the normal semantics)
>> or enabled/disabled via some capability CAP_IMMUNLINK ...
>Capabilities are an area where free bits are even more sparse than
>Filesystem inodes (perhaps I am overstating the problem, as it could
>arguably be overflowed to two words easily).
the capability could, at least for vserver patches,
be combined with any other vserver specific CAP
or, as suggested, not used/defined at all ...
>You have clearly identified that there is a need to allow the System
>Administrator to determine which semantics are followed.
>So, the question is, is it most useful to do this:
> 1. at compile time, via a #ifdef (adding complexity to the code, in
> the form of number of lines of code), with no flexibility but
> complete removability of the code, for the utterly paranoid
> 2. at run time, via a vserver-specific hack, adding complexity to
> the immutable macros but still hard-coding the behaviour
> 3. at run time, via the capability system, adding complexity to the
> two immutable macros and leaving the system administrator having
> to bounce a vserver if they want to let a process unlink some
> files, or do the unlinking from a privileged context.
> 4. on a per-inode basis, using the existing inode attributes system,
> keeping the behaviour of filesystem inodes completely unrelated
> to the process state, or the vserver system.
>My assertion is that the per-inode basis offers the highest level of
>flexibility, and conceptually ties well with the existing behaviour of
>the write bit on UNIX filesystems. It is not a `hack' for vserver -
>it is a backwards compatible enhancement to the immutability
but unfortunately it is not (yet) accepted by the
mainstream, and except for special purpose, like the
vserver system, *not needed* ...
>Are you saying that you are able to correctly predict
>the needs of every system administrator?
of course 8-), they will need
- better, simpler tools
- more features, with less efford
- brilliant documentation, with no need to read
but that is a completely different thing ...
>So, the debate begins. We'll take a vote at the end ;-).
good idea, I just hope, in the end,
we are not the only voters ...
so much for now,