[LU-16524] Limit capabilities of local admin

• Type: Improvement
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.16.0
• Affects Version/s: Lustre 2.16.0
• Labels: patch sec
• Severity: 3
• Assignee: Sebastien Buisson
• Reporter: Sebastien Buisson

Description

We might need to support the use case of a 'local' admin, that is root on the client, also root on Lustre to achieve some tasks such as changing files' owner or group (so root squash cannot be used) but still restricted in some privileged actions (e.g. lfs commands).

Comments

[Peter Jones]

Seems like this body of work has merged for 2.16

[Andreas Dilger]

You are right, this would be somewhat the opposite approach, with the benefit that it would "grant" select privileges to the tenant admin, starting from "nothing" that the regular user has, so would be more "fail safe". The current approach will take away privileges from a root user, but risks that something was missed, or is added in the future that does not add RBAC roles/checks and cannot be squashed/removed.

That said, it definitely belongs in a different ticket so that this one can be marked resolved..

[Sebastien Buisson]

Hi Andreas,

If I understand correctly your comment in https://jira.whamcloud.com/browse/LU-16524?focusedCommentId=370402&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-370402, that would consist in extending the capabilities of a squashed (root) user so that it can still modify file permissions and owners and quotas, if they correspond to a mapped uid/gid/projid.

It seems to be quite the opposite idea of what we implemented with this ticket. The rbac roles are designed to limit the powers of not-squashed root, by preventing modifications of file permissions and owners (file_perms role), or quota modifications (quota_ops role) for instance.

I am not saying that extending the capabilities of a squashed (root) user would not be an interesting feature to have. But I think it is a different approach that should be tackled under a different ticket.

[Andreas Dilger]

Is there anything left to do on this ticket, or should it be marked Resolved/Fixed? My last comment/question about restricting RBAC admin operations to IDs within the nodemap could be addressed in a separate ticket, though it would be nice to also get this into the 2.16 release so that the behavior is consistent.

[Andreas Dilger]

Sebastien, does it make sense for subdirectory mounts that the squashed root on the client is still able to chown/chmod/chgrp for files in the subdirectory tree IF they are for UID/GID/PROJID mapped in the nodemap (excluding root itself)? Similarly, it should only be possible for the squashed root to adjust quotas for UID/GID/PROJIDs that are mapped by the nodemap.

That would allow the root user on the client to do normal admin tasks for files in that project/container, without needing to grant them "real" root access to the filesystem itself (i.e. admin=1).

I think doing the mapped UID/GID/PROJID lookup is fast (this is already done for every RPC) so the only extra check would be whether it was the squashed root user on the client. Maybe an extra "squashed_admin=1" setting or similar?

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50230/
Subject: LU-16524 nodemap: filter out unknown records
Project: fs/lustre-release
Branch: b2_15
Current Patch Set:
Commit: 170ddaa96bdddea32a7c48ddacefc53d961cc783

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50184/
Subject: LU-16524 sec: add fscrypt_admin rbac role
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 22bef9b6c64ef394a2efb41ce1388be71300af0d

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49907/
Subject: LU-16524 sec: enforce rbac roles
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 971e025f5fb77f4eaaa1e9070598dfa6292a9678

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49873/
Subject: LU-16524 nodemap: add rbac property to nodemap
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 5e48ffca322c3c72d3b83b0719f245fc6f13c8e4

[Sebastien Buisson]

I have been testing that further, and found an interesting behavior. Without any LU-16524 patches applied, it is not possible for a squashed root to mount the client if the squash uid or gid does not exist on server side, when SELinux is enabled on the client (either Permissive or Enforced). This is because the client will issue a getxattr request for security.selinux, and on server side user credentials are checked for a getxattr.

With LU-16524 patches applied (especially #50184), even when SELinux is not enabled on the client, it is not possible for a squashed root to mount the client if the squash uid or gid does not exist on server side. This is because patch #50184 adds a user credentials check on getattr.

So I agree patch #50184 introduces a behavior change (only when SELinux is not enabled on the client), but I am not shocked to proceed to a user credentials check on getattr. Moreover, it is questionnable to mount a client as a mis-configured root (a squashed root with its squashed uid or gid that does not exist on server side), given that no further operation is possible on the file system. I would tend to think this is a nodemap configuration error and it should not be supported.