[OpenAFS-devel] Re: [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;

we add an explicit check for inode type?

AFS_ACE_ADMINISTER only means ownership if the inode is a non-directory.  Should

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

are granted due to that status.


answer the question today would be to issue a PR_WhoAmI RPC to the cell's

not be permitted to communicate with the Protection Service and PR_WhoAmI is

standardized for implementation by OpenAFS but at present neither OpenAFS
1.8.x nor 1.9.x include an implementation.


must not be used for this purpose.

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 In the absence of explicit knowledge, the only method by which the client can 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 currently only available from the AuriStorFS Protection Service.  PR_WhoAmI is 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

+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

smime.p7s
Description: S/MIME Cryptographic Signature