About this list Date view Thread view Subject view Author view Attachment view

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 ...
>Reason 1.
>> > [...] 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.

>Reason 2.
>>> 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 ...

>Reason 3.
>>> 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) ...

>Reason 4.
>[from you]
>> 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,


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 28 Jul 2003 - 01:44:06 BST by hypermail 2.1.3