Subject: Re: HSM deisgn goals was: RE: HSM implementation proposal
To: None <tech-kern@NetBSD.ORG, paule@martex.gen.oh.us>
From: Ty Sarna <tsarna@endicor.com>
List: tech-kern
Date: 12/08/1997 10:25:42
[PLEASE wrap your lines at <80 cols, and also fix your Message-ID's!]

In article <01BD03BA.57B3BF40@EOWYN> you write:

> I rather fancy that nothing is going to come of a proposed complete
> HSM.  I'd like to see it happen in the long term though. 

I got the impression that Jason was serious about doing something.

> Toward this goal, can we agree on an intermin framework that's
> growable to support things like "registries" when the time comes? ("if"
> the time comes)

Assuming for the moment that a registry is a good thing (biting my
tongue :->), I don't think a HSM system is where it belongs. Maybe
another VFS. Then again, I think sysctls should be a VFS, and that
hasn't gone very far... Actually, sysctl's are sort of our registry.

> Is this a an agreeable path, I'd like to volunteer some effort to get
> it done.  I'm picturing a simple "/dev/security" and assocated "security
> manager" daemon.  I think this apporach would for the time being make a
> good starting point as we can merge apporate things back to the kernel
> when the time comes. 

With a security manager daemon, you're going to want to cache things in
the kernel for speed, I think. You don't want every permissions check in
the kernel having to go through a context switch and back. Problem is,
if the security manager can make decisions based on arbitraty criteria,
the kernel can't know what criteria were involved and so can't cache
security checks safely.

> In the intermin, the kernel would consult the secuirty manager, with a
> UID and inode, and get back a yes-no/read-write-exec reply. 

My ACL proposal (which I still have yet to write up) is not
significantly more complicated than this, and is a finished product, so
to speak.  Also, it is a security mechanism rather than a filesystem
security mechanism, it works across all filesystems (all filesystems
that are multiuser, anyway) and for other things using a user/group/mode
type scheme (SysV IPC).  (I guess I should write it up the specifics so
people can comment, rather than just talking in general terms about all
the good stuff it does)