Subject: Re: Extended Inode Information
To: Ty Sarna <email@example.com>
From: Sean Witham <Sean.Witham@asa.co.uk>
Date: 12/04/1997 12:56:07
On Wed, 3 Dec 1997, Ty Sarna wrote:
> Regarding someone's comment about wether these attributes should have
> their own permissions, timestamps, etc... great... by the time you get
> done implementing all these cool features, you've essentially duplicated
> the functionality of files. Except now you have two APIs for
> manipulating similar objects, twice as many system utilities (or adding
> new flags to all of them), etc. And you haven't added anything that
> can't be done by just using more plain files. It's sort of analogous to
> RISC vs CISC, and I guess I'm a RISC proponent. Plus, now you have
> headaches when you want to back files up, or sharing them over the
> network, etc.
This is not the case when it comes to the case of security. The
security model as it stands is limited by the inode. To use an
additional file to hold extra security related informaiton is very
dangerous when you consider the daily tasks such as renaming etc.
A tidy managable appraoch would safer when dealling with access rights
to files. A lot of users want a system where they can have lots of
different access rights on a file for the different people and groups
of people they wish to share it with. They may want someone to be a
member of two or more security groups before they have write access to
a file but only need to be in one to get read access. Maintaining
these access rights in a seperate file introduces the complex problem
file associatation for enforcement of the access rights.
> One suggested use for these extended atrributes was to store things like
> the compiled bytecode for a perl script. Why, for heaven's sake? To
> ensure that Perl is a huge pain in the ass to port to other systems? To
> make sure that even on systems with this special functionality that the
> functionality is only availible on some filesystems mounted on a system?
> You can do exactly the same thing with a second file. Python does
> exactly that. If you "import module", it looks for module.py and
> module.pyc. If the .pyc (bytecode) doesn't exists or is older, or has
> abad magic, the .py (source) version is read and compiled, and if
> possible the bytecode will be written to module.pyc, to save time the
> next time it's needed. It's simple, reliable, and portable. Works on
> Unix, Amiga, Mac, DOS, Windows, OS/2, VMS, and who knows what all else.
> Works on any filesystem, and over a network, too.
I do agred that perl could do this with a second associated file. It
depends how useful this cashed bytecode is when you copy files arround
etc or its shared over nfs to different machines. The point is though
if you do use other files to store associated data how do you
associate the file with each other ? OOD seem to be the buz these
days, meta data wouldn't store realted data it would store where to
find the related data and what its relation was.
A the moement we have a crude but effective form of type
identification of a file with the user of /etc/magic but if we wont to
advance from that meta data could be used to define OO status of a
file a combination of a MIME like description and a list of links to
realted files and what their realtions are. try introducing that lot
in a magable backwards compatble form without metadata.
> >From my point of view, it looks like people are inventing excuses to
> implement new functionality without any real reason for it, other than
> it sounds cool.
sounds like how unix got started *8-)
There are real reasons though. The most important I feel is the
extentions to the unix security model model.
> Regarding the HSM thing, I'm beginning to think the single bit
> implementation is the right way to do that, too. Keep the HSM metadata
> in a separate file(s) or database. That way, it can be easily backed up.
> Yes, it causes another reference in some cases, but you can always put
> it on another spindle, if you want. It also means that you can add or
> change the format of the metadata without having to change all the
> system utilities. You can add new methods of indexing it, without having
> to hack the kernel, etc. The amount of kernel support needed to
> implement this would be quite small, really. The kernel just needs to
> consult a daemon on open of files with that bit set. Everything else can
> happen in userland.
Well I prefeer exteneded Inodes for kernel related data such as
exteneding the security model and file association. How you then store
all the extra user-level meta data I don't mind. You can use a strange
form of a hard link if you like that points to other files it an
implementatio feature that doesn't bother me. Still it dosen't matter
how any of this is implemented if its is based on an extendable OO