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

>Summary.
>
>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
>functionality.

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,

best,
Herbert


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