[PATCH 1/2] afs, bash: Fix open(O_CREAT) on an extant AFS file in a sticky dir

[Jeffrey E Altman]

On 5/29/2025 8:11 PM, Jeffrey E Altman wrote:
>
> On 5/19/2025 12:11 PM, David Howells wrote:
>> +int afs_is_owned_by_me(struct mnt_idmap *idmap, struct inode *inode)
>> +{
>> +    struct afs_vnode *vnode = AFS_FS_I(inode);
>> +    afs_access_t access;
>> +    struct key *key;
>> +    int ret;
>> +
>> +    key = afs_request_key(vnode->volume->cell);
>> +    if (IS_ERR(key))
>> +        return PTR_ERR(key);
>> +
>> +    /* Get the access rights for the key on this file. */
>> +    ret = afs_check_permit(vnode, key, &access);
>> +    if (ret < 0)
>> +        goto error;
>> +
>> +    /* We get the ADMINISTER bit if we own the file. */
>> +    ret = (access & AFS_ACE_ADMINISTER) ? 0 : 1;
>
> AFS_ACE_ADMINISTER only means ownership if the inode is a 
> non-directory.  Should
> we add an explicit check for inode type?
I think the answer is 'yes'.  The above check does not work for 
directory inodes so
we need another method of answering the question or informing the caller 
that the
answer is unknown.  In some cases, such as chown() and chgrp() its safe 
to say the
caller is the owner and defer the eventual  access check to the server 
when the inode
is a directory.   However, there are other cases such as check_sticky() 
where the vfs
cannot defer the decision to the server because there isn't an RPC that 
is a one-to-one
match for the decision being made.

In addition to ownership, operations such as chown and chgrp or chmod might
be permitted if the caller is a member of the system:administrators 
group.  The
server has no method of informing the client that the user is special or 
what rights
are granted due to that status.

In the absence of explicit knowledge, the only method by which the 
client can
answer the question today would be to issue a PR_WhoAmI RPC to the cell's
Protection Service to obtain the AFS ID of the task's token.  The AFS ID 
could then
be compared to the struct afs_vnode->status.owner field. However, 
clients might
not be permitted to communicate with the Protection Service and PR_WhoAmI is
currently only available from the AuriStorFS Protection Service. 
  PR_WhoAmI is
standardized for implementation by OpenAFS but at present neither OpenAFS
1.8.x nor 1.9.x include an implementation.

It should be noted that although an AFS ID is provided to the afs client 
when an
rxkad token is inserted into the kernel, the provided value cannot be 
trusted and
must not be used for this purpose.

>
>> +error:
>> +    key_put(key);
>> +    return ret;
>> +}
To address the most urgent need which is the may_create_in_sticky() 
call, perhaps
introduce a non-directory specific is_file_inode_owned_by_me() as part 
of this
change and then address the directory case once we figure out how to 
implement
it.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4276 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20250529/0c189797/attachment.p7s>