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

From: Seiler Thomas (seiler.thomas_at_gmx.net)
Date: Wed 14 Aug 2002 - 01:58:51 BST

Hello everyone.

> I tried out Sam Vilain's unify-dirs script. After running it, I'm
> ---i---------t with lsattr
> or
> 00008010 with showattr.

I habe a question: Is my understanding of these things correct ?

A vanilla 2.4.* Kernel understands only the "immutable flag", that is the
"i" in the output
of a stock lsattr, (or bit the "10" in the output of showattr). If the
Kernel finds this bit set,
no-one (not even root) is able to delete or move the file or to change the
file's content.

So a file with the immutable bit set could not be deleted. even by root on
the main server.
So set / reset the immutable bit, one needs to have CAP_SYS_ATTR so this is
only possible
inside the root server but not inside the vservers.

Then there was the patch by Sam Vilain to the 2.4.16 Kernel, introducing the
"linkage immutable invert bit". It was now possible to protect the file's
and the file's linkage separately. This patch was then included in the
vserver patch.

This makes it possible to share(link) files (e.g. /usr /bin ...) between
The root users could not change the content (and therefor not influence
other vserver)
but they can replace every shared file with a newer version if desired,
affecting only her own vserver without affecting the others.

The initial Kernel Patch by Sam Vilain used bit "8000" of the ext2/3
attributes field for
the "linkage invert flag", because at that time, bit "8000" was the next
unused bit aviable.
And so does the vserver patch.

Then there is this *nice* perl programm "unify-dirs", which tries to
identify identical files in
two or more directories, and then unifies them (by hardlinks). For use with
one would tell the programm to set the immutable and immutable linkage
invert flags.

To see the linkage invert flag, you had to install a special patched version
the ext2progs (lsattr/chattr) which showed the new flag. A stock lsattr did
not show it.

Meanwhile Kernel 2.5.* was programmed. There where some space optimizations
introduced for ext2/3 fs (Until then, the file's tail occupied en entire
block, after
the optimizations, several tail's were merged into the same block, to safe

But sometime files get accessed by others, not by the Kernel, for examle
So care was taken not to use the new optimisation on file which are accessed
A New attribute was needed to tell the kernel not to use the space

Then the kernel developper used bit "8000" as "no-tail" flag, as it was the
next not used flag :-(
lsattr was updated acordingly, and that's why lsattr now
shows ---i---------t
which means for an 2.5 Kernel "immutabel" and "no-tail", but for an
2.4.*-ctx Kernel
this means "immutable" and "immutable linkage invert".

> I wanted the files to be unlinkable, but that doesn't seem to be what's
> happening in practice. (I used -l and -i flags with unify-dirs.)

If the above statement are correct, then the -l -i flags are exactly the
ones needed.

> Could someone help me out here? What should I have for a file that is
> but unlinkable?

You are on the right way (00008010) should be okay.

Have you checked if you have by accident set the immutable flags on the
directories ?
This would prevent changes on the directorie's *content*, aka the filelist,
names, and

If this things are correct, then there is a *conflict* between "immutable
linkage invert" and "no-tail".
If so, shouldn't we switch to the next free bit "10000" as "immutable
linkage invert" ?
This would break existing setups, but i think, it should be simple to write
a little
perl script which sets bit "10000" if bit "8000" was set, and then unsets
bit "8000", so
bit "8000" is free to be used as "no-tail"-bit by the next generation of
linux kernels.

just my 2 cents, though...

Best regards,
Thomas Seiler

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 Wed 06 Nov 2002 - 07:03:42 GMT by hypermail 2.1.3