Re: Permissions

>How about the fact that it would be redundant, that directory
permissions
>already perform this function? How about the fact that it would be
woefully
>inconsistent with the fact that filenames do not belong to a file but
belong
>to the directory they are contained in? The identity of a file is in
its
>stats and its contents, the filename is an identifier /separate/ from
the
>file. A file remains the same whether it has one, two, many, or even
/zero/
>filenames; moving a file does not change it, neither does hard linking
it.

I agree that it would be redundant, given the fact that the directory
already
has permissions assigned to it by itself. However, the concept of
"directory"
in VSTa is slightly different than in other OS's. Usually, the
filesystem
directory item corresponds to an array somewhere on the disk, each entry
having a name, length, access permissions, and file allocation
information.
In VSTa a directory is an arbritrary collection of objects, not
necessarily
a collection _owned_ by anyone.

Consider a server that handles TCP/IP connections. It may publish a
directory view of the currently open connections. For example, a file
named 12.34.56.78:23(99), could identify a telnet connection using
local port 99. Who owns the directory containing these files? It would
be inappropriate to allow any old user to monitor the network activity
of the entire system by listing this directory. It would make sense
though, for them to be able to list their own connections, as well as
read, write, and stat them.

You could argue in that case, that each user's connections should be
kept in a per-user subdirectory of that server's directory structure.
IMO, that would add unnecessary complexity. It would be a lot easier
if we adopt the simple rule that users can't see what they can't read.

>If anything, I don't agree with user permissions in the first place.
Access
>rights should be embedded in the topology of the filesystem, which
should
>in turn allow multiple containment (multiple parents for any directory)
>in order to properly embed arbitrary access rights. If you do this then
>you end up with a secure system that doesn't require each and every
single
>file server to authenticate every user at every turn (with the
unresolvable
>security issues /that/ raises).

In VSTa, that problem is solved by the kernel passing a trusted
structure to
every server on MSG_CONNECT. Granted, it is up to the server to properly
interpret that structure, but it keeps things simple on the kernel and
more
importantly, decentralized.

There's is nothing in VSTa which contradicts hard linking, it just isn't
implemented the way things are set up. I think in order to do that
correctly,
you'd have to divide the stat query response into two parts: a per-entry
section (name, and permissions if you want), and a per-file section
(size,
revisions, time & date, etc.) In which section the permissions are kept
can
be up to the file system, just as it's clear to the client where that
information is being kept.

Eric
Received on Wed Nov 11 04:33:19 1998