Here goes my $0.02..

I'd favor a two-tier approach where security and user associations are =
isolated.

Security would be based upon an ACL virtual file. Similar to procfs. =
That is, a special directory of ACL's which are hashed etc. The only =
extension to an Inode would be the associated Inode if any of it's ACL =
file on the special ACL VFS. This would allow incredibly complex =
security with the advantage that ACL's are centrally manageable in a =
manner similar to /etc/group without textfile overhead.

It would destroy the idea of a file being a file. We'd have a NT/VMS =
like registry that's mounted as a special dir tree. (or maybe not =
mounted.) I kinda feel like /etc/ should be nothing more than a "procfs" =
like translator interface to a special file. A registry that's got an =
ASCII in/out under /etc/ and a formatted binary on under /registry (I'm =
sure a lot of people didn't want to hear that! ;))

User associations would be based upon a smart magic type of mechanism. =
Where when the user opens a file, the kernel checks for a registered =
"file-assocator" for that user/process. It then passes the =
filename/inode to the daemon, instead of doing anything, and the daemon =
passes back the new command line or binary loader info needed. (That way =
we can to TOPS20 compile/execute on demand and for one ".c" file and =
open emacs for another depending on the users preference.)

Like I said, just my opinion. I'm starting to think a userland vnode =
driver that implements HURD-like special files is needed.

For example, why can't a users home "/home/user" be a vnode driver that =
mounts an encrypted "/home/user.data" using the supplied login password. =
(Now that would be cool.)

To make a long story short, we need an analogue of the HURD translator =
mechanism and a separate ACL mechanism,

I think ACL's are too big.and complex to really be part of the =
file-system, they should be part of the "system" as such.=20

If you've gotten this far: thanks for listening! Hope something make =
sense.

Happy Holidays.

	-Paul


-----Original Message-----
From:	Sean Witham [SMTP:Sean.Witham@asa.co.uk]
Sent:	Thursday, December 04, 1997 7:56 AM
To:	Ty Sarna
Cc:	tech-kern@NetBSD.ORG
Subject:	Re: Extended Inode Information



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.
=20
> 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.=20
> Works on any filesystem, and over a network, too.=20
>

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

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

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
principle

--Sean