[LU-5966] Resolve DLC and root squash potential conflict

• Status: Open
• Project: Lustre
• Type: Improvement
• Priority: Minor
• Reporter: Amir Shehata (Inactive)
• Assignee: Amir Shehata (Inactive)
• Resolution: Unresolved

Description

From: Grégoire Pichon [e-mail]
Sent: Thursday, November 27, 2014 4:38 AM
To: Shehata, Amir
Cc: Sebastien Buisson; Jones, Peter A
Subject: Dynamic LNet Config and Root squash

Hi Amir,

I have seen your patches related to the Dynamic LNet Configuration have been landed into master for the future 2.7 Lustre version.

Have you addressed the issue that was raised earlier this year about dynamic NID modification and the consequences on the root squash functionality (need to re-compute the flag LL_SBI_NOROOTSQUASH), as described in the mail thread below ?

Regards,
Grégoire.

----Message d'origine----
De : Grégoire Pichon
Envoyé : vendredi 21 février 2014 10:20
À : Shehata, Amir; Jones, Peter A
Cc : Sebastien Buisson
Objet : RE: Root Squash

Amir,

I would rather implement a service that allows components to register/unregister for LNet configuration changes. Component would provide a callback function. When LNet configuration occurs, each callback function would be called, allowing components to be notified of the change.

This avoids creating an additional thread (one for each component interested in LNet configuration change).
The callback functions would be executed in the ioctl processing (user process context), which is fine I think.

Anyway, I think this can be handled later in a separate patch. Both patches #8023 and #5700 are fully functional. The situation where nosquash_nids parameter is set and LNet configuration is updated is only a corner case.

Peter, would you agree handling this in a separate patch after #8023 and #5700 patches are independently landed ?

Regards,
Grégoire.

----Message d'origine----
De : Shehata, Amir [e-mail] Envoyé : mercredi 19 février 2014 19:02 À : Grégoire Pichon; Jones, Peter A Cc : Sebastien Buisson Objet : RE: Root Squash

Hi Gregoire,

You can call a function defined in the lustre world, but it'll get executed in the context of the ioctl processing (which gets executed in the user process context). This function can then post an event on a queue which a lustre thread would be waiting on, and then it would wake up and process the update.

I've been looking at the code, the example I found is in ptlrpc:
liblustre_check_events()>ptlrpc_master_callback():void (*callback)(lnet_event_t *ev) = cbid>cbid_fn;

if you do a tag search on cbid_fn:
examples: client_bulk_callback(),server_bulk_callback()

these functions contain code similar to:
wake_up(&req->rq_reply_waitq);

Which I believe wakes up a waiting queue.

I haven't spent much time around this code, so maybe someone from the lustre world, might be better able to assist on how this exactly works.

Thanks
amri

----Original Message----
From: Grégoire Pichon [e-mail]
Sent: Monday, February 17, 2014 9:11 AM
To: Jones, Peter A; Shehata, Amir
Cc: Sebastien Buisson
Subject: RE: Root Squash

Hi all,

I don't see any problem with letting DLC land first. I will try to post my patch on top of patch #8023, but I already depends on patch #9221. Not sur how to deal with such a double dependency from two different branches. Hopefully, #9221 should be able to land soon.

I am currently preparing a new version of the root squash patch (http://review.whamcloud.com/#/c/5700/) that mostly rebase on current master (and therefore addresses Andreas's comments). This new version will probably implement a dedicated routine that checks the nosquash_nids list agains client's nids and update the LL_SBI_NOROOTSQUASH flag. This routine would be exported so it could be called from LNetCtl() when nids are added/removed.

I think there might be a problem with calling this routine from lnet module. This would mean lnet requires a symbol from lustre module ?
How should I handle this cross component call ?

Grégoire.

----Message d'origine----
De : Jones, Peter A [e-mail] Envoyé : lundi 17 février 2014 17:13 À : Shehata, Amir; Grégoire Pichon Cc : Sebastien Buisson Objet : Re: Root Squash

Thanks Amir.

Gregoire, how about you create a new version of your patch dependent on this patch? That way, if - as hoped - DLC lands ahead of feature freeze for 2.6 this version of the patch can land, but we can still fall back to your current version if it does not. I would expect that the current version of the root squash patch can also be used as an interim measure on pre-2.6 releases.

On 2/17/14, 7:56 AM, "Shehata, Amir" <[e-mail]<[e-mail]>> wrote:

Hi Peter,

Here is the patch which introduces the ability to change the NIDs from ioctl.

http://review.whamcloud.com/#/c/8023/

Thanks
amir

From: Jones, Peter A
Sent: Friday, February 14, 2014 3:10 PM
To: Shehata, Amir; Grégoire Pichon
Cc: Sebastien Buisson
Subject: Re: Root Squash

Amir

Is it possible to point to a specific gerrit change set that contains the changes that will be significant for the root squash changes? If so, can we define the dependency in gerrit and then ensure that this change is included in the list of patches being tracked for this feature?

Peter

On 2/14/14, 8:45 AM, "Shehata, Amir" <[e-mail]<[e-mail]>> wrote:

Hi Gregoire,

Sorry, forgot to mention in my previous e-mail is that most likely DLC is slated to land in 2.6. So if your patch lands before DLC, then we'll need to refresh the patch (or create a new Bug to track the changes). I'm guessing though that we wouldn't want to deliver 2.6 with the bug that would be caused to root squash by DLC. I can coordinate with you, to pull in the change to root squash into the DLC patch.

So your patch would land before DLC, then I would sync my working branch with the latest, and we can collaborate to add the change in DLC patch, so that When DLC patch lands, it will have the required change.

Another option, is to delay the patch landing until DLC lands, then make the necessary changes, refresh the patch and land it then, before releasing 2.6

Maybe Peter, would be best suited to point out the best approach.

Thanks
Amir

From: Grégoire Pichon [e-mail]
Sent: Friday, February 14, 2014 12:59 AM
To: Shehata, Amir
Cc: Sebastien Buisson; Jones, Peter A
Subject: RE: Root Squash

Hi Amir,

Root squash is a security feature which controls super user access rights to an Lustre file system. The root squash feature works by re-mapping the user ID (UID) and group ID (GID) of the root user to a UID and GID specified by the system administrator, via the Lustre configuration management server (MGS). The root squash feature also enables the Lustre administrator to specify a set of client for which UID/GID re-mapping does not apply.
It is managed by two configuration parameters, root_squash and nosquash_nids. The root_squash parameter specifies the UID and GID with which the root user accesses the Lustre file system. The nosquash_nids parameter specifies the set of clients to which root squash does not apply.LNET NID range syntax is used for this parameter.

The patch I am working on comes from a issue faced by one of our customer (CEA) where root squash is not properly enforced (LU-1778). Root squash exhibits inconsistent behavior on a client when enabled. If a file is not cached on the client, then root will get a permission denied error when accessing the file. When the file has recently been accessed by a regular user and is still in cache, root will be able to access the file without error because the permission check is only done by the client that isn't aware of root squash. The patch adds root squash settings to llite so that client is able to apply root squashing when it is relevant.

The point I am concerned with is related to the nosquah_nids parameter and the new dynamic LNet configuration feature. The current version of my patch computes a flag LL_SBI_NOROOTSQUASH that tells if root squash should be applied or not by the client. When the nosquash_nids parameter is recorded, the list of specified nids is compared to the list of nids of the client. As soon as one of the client nids matches a nid of the nosquash_nids list, the flag LL_SBI_NOROOTSQUASH is set and root squashing does not apply. This design is based on the fact that client nids does not change during the life of llite component, which will no more be the case with dynamic LNet configuration.

With dynamic LNet configuration feature, the LL_SBI_NOROOTSQUASH flag should be re-computed each time a nid is added or removed. Another option would be to check the nosquash_nids list against client nids each time ll_inode_permission() is called but I suppose this would impact performance too much. If you see other ways to address the problem, just tell me !

If you would like to discuss this by phone, I am afraid our timezones do not overlap much. I can still propose a call on Monday or Wednesday 8am PST / 5pm CET. Here is my phone number: [phone].

Thanks,
Grégoire.
–
Grégoire PICHON
Parallel File Systems Engineer
Bull Extreme Computing R&D

De : Shehata, Amir [e-mail] Envoyé : jeudi 13 février 2014 20:21 À : Jones, Peter A; Grégoire Pichon Cc : Sebastien Buisson Objet : RE: Root Squash

Hi Gregoire,

I think a conference call would be best, but if you can just give me a summary of your concerns, so I can come to the meeting prepared. Basically DLC provides a way to configure LNet dynamically, but it's backwards compatible. Meaning the original way of configuring LNet is still valid. Are your concerns regarding the code changes, or a change in feature details?

If you could let me know a good time for a conference call, that would be great.

Thanks
amir

From: Jones, Peter A
Sent: Thursday, February 13, 2014 9:07 AM
To: [e-mail]<[e-mail]>
Cc: Shehata, Amir; Sébastien Buisson
Subject: Root Squash

Hi Gregoire

I would like to introduce Amir, who is the lead engineer on the Dynamic LNET Config project. He would like to understand more fully your concerns of overlap between this project and your work in progress under LU-1778. Is this something that you could elaborate on via email or would it make sense to setup a concall to talk it over directly?

Thanks

Peter