[LU-14968] add password for project files

• Type: New Feature
• Resolution: Unresolved
• Priority: Minor
• Assignee: WC Triage
• Reporter: Hongchao Zhang

Description

Allow admin to add password to protect the files owned by some project

Issue Links

• is related to: LU-13335 add name lookup for project IDs

Comments

[James A Simmons]

If I remember right you can store information like this in ldap as non-standard information.

[Sebastien Buisson]

The proposal of setting a password by the administrator via the lctl command raises the question of where and how this password is going to be stored. I guess it would be stored on server side, but it cannot be stored in clear text for security reasons.

Then, when you need to check if the password in the user's session keyring matches the one set by the administrator, how are you going to proceed? It would require sending the password over the wire between client and server, which again raises the question of how this is secured. Obviously it cannot be sent in clear text.

I like the idea of using passwords for Unix groups, because it is already available and works at the Linux level instead of Lustre. This is just like other access control mechanisms like Unix permissions that admins are used to managing and synchronizing over a whole cluster. And I think it achieves what you are looking for: just like project IDs are inherited from the parent directory, you can use the setgid bit to inherit the GID.

[Andreas Dilger]

Can you please provide more detailed information for this. What is this feature for, and how is it expected to be used? The current one-line summary is not at all clear what this is requested. My guess is that you want to add password control to allow users to change the projid on their own files. I think that would be reasonable to implement, as described below. It may even be that we don't want password control to set the projid, but rather fine-grained control of which projects a user can change their files to?

Or is this something different like using projid to control access to a file/directory? That would not be a good idea to implement IMHO, since it is essentially adding a lot of complexity and could instead be done today by using GID to access the files. One of the main benefits of projid is that it does not control access to a file like GID does, so files with the same projid can not necessarily be accessed by all users in that project.

Please provide an overview of how it will be implemented.

Is the current mechanism to allow users in an admin group (mdt.*.enable_chprojid_gid) enough? How is this password integrated with existing permission mechanisms (if at all)? There is a lot of work that would need to be done to integrate this directly with existing permission methods (e.g. login, processes, etc.), but using an existing mechanism like sudo to just change the projid of existing files would be much easier, and have a much lower security risk.

It would make sense to first implement the /etc/projid file from LU-13335 to allow setting projid by name, and then extend /etc/projid to include a list of users allowed to change files to that group, like:

# project:projid[:description[:users]]
proj1:2000001:group project:adilger,hongchao,laisiyao
proj2:2000002:user2 project:adilger
proj3:2000003:user3 project:hongchao

The password control could be implemented by a utility called via "sudo", possibly changing to a special "chproj_grp=CHPROJ_GID" admin group, that matches "mdt.*.enable_chprojid_gid=CHPROJ_GID" with some rules that check which user/UID can use each projid. Running this under a group (that has no other file access permissions) is much less of a security risk than requiring the process be done as the root user. However, the tricky part is that this process would still need access to the directory tree/files in order to change the projid.

It would make sense to have a standalone "lchproj" binary that shares the code from "lfs_project.c" but is not part of "lfs", which is too complex to be totally safe to run under sudo. The lchproj binary should have as few lines of code as possible, to minimize bugs/ways to break security. Running "lchproj [lfs project options] <file|dir>" would have the same arguments as running "lfs project", but it could internally execute "sudo -g chproj_grp lchproj ..." if lfs_project_set() fails with EPERM (i.e. when not run as root, and the if user is not already in the chproj_grp). At that point sudo would prompt the user for their own password, change to the chproj_grp group, and run lchproj to call lfs_project_set(). That would still require chproj_grp to be configured on the client, and the MDS to have mdt.*.enable_chprojid_gid=CHPROJID_GID set instead of the default =0 that limits this to root. Running sudo is allowed again without a password for 5 minutes after the initial password was given, which should be enough for most uses.

Alternately, it might be possible for the MDS to have an upcall like l_getprojid, similar to l_getidentity, that reads /etc/projid to determine which UID can set which projid, and avoid needing a password at all. The MDS would keep a cache of these UID->projid mappings like it does for UID->GID, and then no passwords would be needed at all. The mdd_fix_attr() would just check if the UID has access to the specified projid and allow it, or not. This has the benefit of avoiding the need to configure something on every client, and potential security issues with sudo, but has the drawback that it would need code changes on the MDS while lchproj could potentially be installed on any existing client and not need any changes to Lustre at all.