<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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)).</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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).</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">If you want a bit more context:<a href="https://review.whamcloud.com/c/fs/lustre-release/+/49539" id="LPlnk751043">https://review.whamcloud.com/c/fs/lustre-release/+/49539</a></span></div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Aurélien</span></div>
<div class="elementToProof"><span style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>De :</b> lustre-discuss <lustre-discuss-bounces@lists.lustre.org> de la part de Bertschinger, Thomas Andrew Hjorth via lustre-discuss <lustre-discuss@lists.lustre.org><br>
<b>Envoyé :</b> mercredi 24 janvier 2024 09:23<br>
<b>À :</b> Kira Duwe via lustre-discuss <lustre-discuss@lists.lustre.org><br>
<b>Objet :</b> [lustre-discuss] question on behavior of supplementary group permissions</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">External email: Use caution opening links or attachments<br>
<br>
<br>
Hello,<br>
<br>
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:<br>
<br>
$ cat /lustre/problem_file<br>
cat: /lustre/problem_file: Permission denied<br>
$ stat /lustre/problem_file<br>
(succeeds)<br>
$ cat /lustre/problem_file<br>
(succeeds)<br>
<br>
We've only observed this on particular client/server pair:<br>
<br>
client kernel: 3.10.0-1160.95.1<br>
client lustre: 2.15.3<br>
server kernel: 4.18.0-477.21.1<br>
server lustre: 2.15.3<br>
<br>
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.<br>
<br>
I have 2 questions about this. The big one is, section 41.1.2.1 of the Lustre manual claims:<br>
<br>
> 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.<br>
<br>
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...)?<br>
<br>
Or is the manual wrong/out of date here?<br>
<br>
My second question is, assuming the behavior described above is a bug, are there any known issues here that we could be running into?<br>
<br>
Let me know if I can provide any more information.<br>
<br>
Thanks,<br>
Thomas Bertschinger<br>
_______________________________________________<br>
lustre-discuss mailing list<br>
lustre-discuss@lists.lustre.org<br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org">http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org</a><br>
</div>
</span></font></div>
</body>
</html>