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

From: Sam Vilain (sam_at_vilain.net)
Date: Mon 28 Jul 2003 - 00:20:58 BST


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.

Reason 2.

> > This breaks the normal immutable semantics. On the other hand, this
> > would be fine if it was a configurable behaviour.

Reason 3.

> > You will still need the split immutability macros, so all it saves you
> > is one bit per inode.

I don't think that even half of the relevant bits have been used so
far...

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

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.

Are you saying that you are able to correctly predict the needs of
every system administrator?

So, the debate begins. We'll take a vote at the end ;-).

> no, I disagree, it's not about registering this
> bit, it's about having to maintain (set/unset) this
> bit which requires tool support and filesystem support
> which, IMHO is not required at all ...

This isn't actually all that hard. I implemented a patch for the
e2fsprogs suite - including a well written manual page for it - and
sent it to T'so, which of course was ignored completely :-).

http://www.vilain.net/immutable/e2fsprogs-1.25-immutable-link.patch

On the other hand, this would mean that all of the other filesystems'
tools would need to handle the extra attribute as well.

So, I can see where you're coming from - so, to pre-empt one iteration
of the debate, my rebuttal is - how many other filesystems support
e2fsprogs-style inodes attributes at all?

-- 
Sam Vilain, sam_at_vilain.net

Information is not knowledge Knowledge is not wisdom Wisdom is not truth Truth is not beauty Beauty is not love Love is not music - anon.


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 - 00:39:47 BST by hypermail 2.1.3