Re: Permissions

vandys@cisco.com writes:

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

do_wstat in statsup.c handles what most servers will need to do.
I had a slightly different case because I was basing my struct
prots off of a file in the outside filesystem, so I had to rstat
those fields and set them manually.

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

Got it. That's what the "owner" stat is for. This makes a lot of sense.
It was really throwing me off because a number of hardware
servers were returning owner=0, when there is no UID 0. One
server (fd) was even returning owner=1/1, which is a
permission, not a UID.

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

I've got it now. It becomes easier to see once you play with the "ids"
command a little. I've looked at login.c and I see how it uses perm_ctl
to give the user their assigned ids. I'm going to try to create a
command to let the user muck around with their permissions in the
shell. It wouldn't be able to change the real shell's permissions (I
don't think), but it certainly could let you launch programs with
forged ids, etc.
 
>>>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?

I agree completely.

>Eric
Received on Thu Oct 29 02:47:09 1998