https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-14968 Lustre <p>Allow admin to add password to protect the files owned by some project</p> LU-14968

add password for project files

New Feature Minor Open Unresolved Hongchao Zhang Hongchao Zhang Fri, 27 Aug 2021 09:27:01 +0000 Wed, 1 Sep 2021 15:44:15 +0000 0 5 <p>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 <b>guess</b> 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?</p> <p>Or is this something different like using projid to control <b>access</b> to a file/directory? That would <b>not</b> be a good idea to implement IMHO, since it is essentially adding a <b>lot</b> 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 <b>not</b> 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.</p> <p>Please provide an overview of how it will be implemented.</p> <p>Is the current mechanism to allow users in an admin group (<tt>mdt.&#42;.enable_chprojid_gid</tt>) enough? How is this password integrated with existing permission mechanisms (if at all)? There is a <b>lot</b> 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 <tt>sudo</tt> to just change the projid of existing files would be much easier, and have a much lower security risk. </p> <p>It would make sense to first implement the <tt>/etc/projid</tt> file from <a href="https://jira.whamcloud.com/browse/LU-13335" title="add name lookup for project IDs" class="issue-link" data-issue-key="LU-13335">LU-13335</a> to allow setting projid by name, and then extend <tt>/etc/projid</tt> to include a list of users allowed to change files to that group, like:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># project:projid[:users] proj1:2000001:adilger,hongchao,laisiyao proj2:2000002:adilger proj3:2000003:hongchao </pre> </div></div> <p>The password control could be implemented by a utility called via "<tt>sudo</tt>", possibly changing to a special "<tt>chproj_grp=CHPROJ_GID</tt>" admin group, that matches "<tt>mdt.&#42;.enable_chprojid_gid=CHPROJ_GID</tt>" 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.</p> <p>It would make sense to have a standalone "<tt>lchproj</tt>" binary that shares the code from "<tt>lfs_project.c</tt>" but is not part of "<tt>lfs</tt>", which is too complex to be totally safe to run under <tt>sudo</tt>. The <tt>lchproj</tt> binary should have as few lines of code as possible, to minimize bugs/ways to break security. Running "<tt>lchproj <span class="error">&#91;lfs project options&#93;</span> &lt;file|dir&gt;</tt>" would have the same arguments as running "<tt>lfs project</tt>", but it could internally execute "<tt>sudo -g chproj_grp lchproj ...</tt>" if <tt>lfs_project_set()</tt> fails with <tt>EPERM</tt> (i.e. when not run as root, and the if user is not already in the <tt>chproj_grp</tt>). At that point <tt>sudo</tt> would prompt the user for their own password, change to the <tt>chproj_grp</tt> group, and run <tt>lchproj</tt> to call <tt>lfs_project_set()</tt>. That would still require <tt>chproj_grp</tt> to be configured on the client, and the MDS to have <tt>mdt.&#42;.enable_chprojid_gid=CHPROJID_GID</tt> set instead of the default <tt>=0</tt> that limits this to root. Running <tt>sudo</tt> is allowed again without a password for 5 minutes after the initial password was given, which should be enough for most uses. </p> <p>Alternately, it <em>might</em> be possible for the MDS to have an upcall like <tt>l_getprojid</tt>, similar to <tt>l_getidentity</tt>, that reads <tt>/etc/projid</tt> to determine which UID can set which projid, and avoid needing a password at all. The MDS would keep a cache of these UID-&gt;projid mappings like it does for UID-&gt;GID, and then no passwords would be needed at all. The <tt>mdd_fix_attr()</tt> would just check if the UID has access to the specified <tt>projid</tt> and allow it, or not. This has the benefit of avoiding the need to configure something on every client, and potential security issues with <tt>sudo</tt>, but has the drawback that it would need code changes on the MDS while <tt>lchproj</tt> could potentially be installed on any existing client and not need any changes to Lustre at all.</p> <p>The proposal of setting a password by the administrator via the <tt>lctl</tt> 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.</p> <p>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.</p> <p>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 <em>think</em> it achieves what you are looking for: just like project IDs are inherited from the parent directory, you can use the <tt>setgid</tt> bit to inherit the GID.</p> <p>If I remember right you can store information like this in ldap as non-standard information.</p> Related LU-13335 Development Rank 1|i022wf: Rank (Obsolete) 9223372036854775807