On 10/25/2014 3:35 PM, Nathaniel W Filardo wrote: > Hello all, > > At present, GIDs seem a little funny -- it takes system:administrator > membership to change them, but files can be created with arbitrary GID > simply by operating a client with a UNIX credential whose primary GID is > whatever is desired.
The actual requirements for setting the ownership and/or group of a
vnode are
1a. Insert permission on the directory
1b. Ownership of the file
or
2. Member of system:administrator group
or
3a. Owner can be changed if the volume owner is the object owner
3b. Group can be changed if the volume group is the object group
In addition, the volume owner has implicit Administrator permission and
can grant themselves Insert permission for the purpose of changing the
owner or group on any object.
> I would like to propose a flag for file servers which permits the volume
> owner to change the UNIX GID of objects on that volume, so long as the
> setuid and setgid bits are not set.
Since a volume owner already has implicit Admin permission, is this
necessary?
> 1) Check_PermissionRights contains the comment
>
>> /* bypass protection checks on first store after a create
>> * for the creator; also prevent chowns during this time
>> * unless you are a system administrator */
>
> But there's nothing temporal about the test being done above it:
>
>> if ((rights & PRSFS_INSERT) && OWNSp(client, targetptr)
>> && (CallingRoutine != CHK_STOREACL)
>> && (targetptr->disk.type == vFile)) {
>
> So I think the upshot is that having PRSFS_INSERT rights in a given
> directory is enough to confer write permissions to any file owned by you in
> that directory?
There are no descriptors or handles in AFS protocol to maintain server
side state for an "open" or "create". The server grants the
permissions based upon Insert and the cache managers take them away as
required by the local OS behavior.
> 2) The first chunk of code commented out with #ifdef USE_GROUP_PERMS (that
> symbol seems to never be defined anywhere) overlooks cases considered in the
> #else branch. Defining it would eliminate the ability ("kludge") of a user
> to read her own files which lacked UNIX owner read permission. The second
> chunk looks fine. Should the first chunk be adjusted?
Mode bits are stored for the benefit of UNIX they are not an AFS
capability. Not all operating systems use mode bits. Sites can
activate that code if they are running a UNIX only environment but it
would not be appropriate for a call with non-UNIX clients.
> 3) CREATE_SGUID_ADMIN_ONLY is defined twice in the file, once up top and
> once mid-way through. Is this a kind of trap for would-be code mutators
> like yours truly and the third test is somehow dramatically more important
> than the first two, or is it just lingering junk? ;)
The first one was added by 30433f36a953187f27b5db9fb432f3b7dce91e6b when
the second one already existed later in the file. The second should
have been removed as part of 30433f36a953187f27b5db9fb432f3b7dce91e6b.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
