If I remember correctly, the Lustre client is sending at most 2 GIDs into its RPC, in addition to its effective GID, those are the file GIDs related to the operation you're trying to do. (2 GIDs if you're doing an operation on 2 files (ie: rename)).
In your case, this is just open, so I think the client will send only its effective FS GID and the file GID. However this is an open, and it is likely that the intent RPC does not fetch the file metadata prior to do the open, so the client is not telling the MDT that this user is already a member of that file group. The MDT has no way to know it (identity_upcall = NONE). This is a bug/limitation of identity_upcall = NONE (which is not the standard deployment). The "fix" would be for the client to either send all the supplementary groups the user is member of (used to be done prior to 2.6, but note sure this is a good thing), or the client should retrieve file metadata before sending the open RPC, which will impact open perf a lot. If you want a bit more context:https://review.whamcloud.com/c/fs/lustre-release/+/49539 Aurélien ________________________________ De : lustre-discuss <[email protected]> de la part de Bertschinger, Thomas Andrew Hjorth via lustre-discuss <[email protected]> Envoyé : mercredi 24 janvier 2024 09:23 À : Kira Duwe via lustre-discuss <[email protected]> Objet : [lustre-discuss] question on behavior of supplementary group permissions External email: Use caution opening links or attachments Hello, We have a curious issue with supplemental group permissions. There is a set of files where a user has group read permission to the files via a supplemental group. If the user tries to open() one of these files, they get EACCES. Then, if the user stat()s the file (or seemingly does any operation that caches the inode on the client), the next open() attempt succeeds. Interactively, this looks like: $ cat /lustre/problem_file cat: /lustre/problem_file: Permission denied $ stat /lustre/problem_file (succeeds) $ cat /lustre/problem_file (succeeds) We've only observed this on particular client/server pair: client kernel: 3.10.0-1160.95.1 client lustre: 2.15.3 server kernel: 4.18.0-477.21.1 server lustre: 2.15.3 We have mdt.*.identity_upcall=NONE set on every server. Also, we cannot reproduce the issue with newly created files; it only appears to affect a set of existing files. I have 2 questions about this. The big one is, section 41.1.2.1 of the Lustre manual claims: > If there is no upcall or if there is an upcall and it fails, one > supplementary group at most will be added as supplied by the client. To my reading, this suggests that the "bug" we observe above is actually the correct behavior. Well, the manual is not precise about which single supplementary group will be supplied by the client, but the relevant group in this case is not the first supplemental group in the user's group list, it's in the middle of the list. So my question is, is the Lustre manual accurate (and then my followup question is, if so, why do supplemental group permissions appear to work for us in most cases...)? Or is the manual wrong/out of date here? My second question is, assuming the behavior described above is a bug, are there any known issues here that we could be running into? Let me know if I can provide any more information. Thanks, Thomas Bertschinger _______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
