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
