Re: Permissions

[Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:]

>I know what the "perm" and "acc" stat fields do, but I still
>get confused dealing with "struct perm". Does that one handle
>both fields?

No; in fact, it's "struct prot". "struct perm" describes abilities which a
USER has; "struct prot" describes the protections of some filesystem object.
When you stat something you're looking at its "struct prot". Why did I name
the supporting routine "perm_print"? Must've been a bad day....

>When I read in an "acc" field from rstat(),
>I've been doing an atoi on the first value for the default
>access, skipping to the "/", and then calling the library
>function to read in the rest. Is this right?

Actually, permpr.c and permsup.c in vsta/src/lib, along with statsup.c
provide most of the routines to handle these data structures.

>UIDs and GIDs: Do their values relate to the perm values,
>or are they completely different?

Different, and a later evolution in the whole permission/protection scheme
of the world.

UID is associated with a permission, and is basically an indication of who
is holding a permission. So lots of users may have sys.sys, but for
purposes of accounting if nothing else, a server may want to know more about
the identity of the sys.sys wielder. This is why a UID got added. It also
provides an escape hatch for when you completely revoke ACC_CHMOD from a
file you own. Without a special case for UID, the only way to get back at
the file would be to edit the underlying blocks of the filesystem with a
binary editor. I was doing just such a thing when I realized I needed for
the user holding a UID to always be permitted to CHMOD the object.

GID is different; it's a way of indicating zero or more permissions which
should be granted. Being a member of a group means you inherit each of
these permissions. So the user "root" is a member of GID "99", which if you
look in vsta/etc/group has a list of exactly one, zero-length, permission.
OTOH, "vandys" is in group 0, which is granted sys.sys. If you log in as
"vandys", not only do you get the user's private permission (usr.vandys),
but also anything granted in group 0.

>The docs seem to say
>that they are the same, but I'm confused. When you log on
>as root, you get usr.root for your default permission, via
>the line in /vsta/etc/passwd. In order to get the real
>root permission, you'd have to be in the group (I think
>it's 99), not the usr group.

No, root gets its own permission (usr.root), but then its list of
permissions is enhanced by adding the zero-length "super" group permission.
The "root" account is in group 99 (the fourth field of the record, I
believe). I guess the fact that his UID is 99 makes that a little less
clear, sorry.

>Also, in POSIX you can stat() a file you don't have read
>access to. In VSTa you cannot, because you would have to
>FS_OPEN it first. This causes utilities like gls and vls to
>bail out when there are private files that you don't own in
> a directory. In VSTa the only thing you know about a file
>you can't read is its name.

This mostly seems like a feature to me, although it causes wrinkles like the
one you noticed. Setting aside legacy behavior, why should somebody who
isn't supposed to read your file be permitted to know when and how much you
wrote it, and also when you read it?

>Kernel stuff: "struct port" in the kernel corresponds to
>"port_name" in a program, which is global across all processes
>(i.e., they can send port names to each other). "struct
>portref" in the kernel corresponds to "port_t", which is
>specific in each process and can't be shared across processes.
>Is this right?

Right, port_name's are global, and port_t's (on top of which file
descriptors are emulated) are a per-process resource.

>One last thing: the values for the "type" stat field. I see
>f is for file (FS_SEEKable), and d is for directory. c is for
>a TTY (not FS_SEEKable, returns true on isatty). "b" and
>"s" refer to block devices; what's the difference? "fifo"
>is a pipe (no FS_SEEK). "x" means other device (only
>FS_STAT)?

I think there's also "null", for fast-stub /dev/null emulation in libc. I'm
not at all convinced there's a difference between "b" and "s". The only
really critical one is "c", because a bunch of TTY processing happens behind
your back. More than one person has spent time with their brand-new server
trying to figure out what's happening to their data because they cribbed
their code from a TTY server. :->

                                                        andy
Received on Wed Oct 28 07:08:06 1998