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-3811 Lustre <p>Non-root users cannot archive their files and root cannot archive files owned by other users. Moreover the lfs hsm_archive command fails silently. To reproduce, start HSM and do the following:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># cd /mnt/lustre # dd if=/dev/zero of=Asterix bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.0633262 s, 166 MB/s # chown sanity: Asterix # lfs hsm_archive Asterix # echo $? 0 </pre> </div></div> <p>Running the same operation with trace enabled show that the failure originates from:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>00000004:00000001:3.0:1377109173.525959:0:15687:0:(mdd_object.c:911:mdd_xattr_sanity_check()) Process leaving (rc=18446744073709551615 : -1 : ffffffffffffffff) 00000004:00000001:3.0:1377109173.525959:0:15687:0:(mdd_object.c:1034:mdd_xattr_set()) Process leaving (rc=18446744073709551615 : -1 : ffffffffffffffff) 00000004:00000001:3.0:1377109173.525964:0:15687:0:(mdt_hsm.c:77:mdt_hsm_attr_set()) Process leaving (rc=18446744073709551615 : -1 : ffffffffffffffff) </pre> </div></div> <p>The failure in mdd_xattr_sanity_check() is because the file ownership is not root and the coordinator runs with no capabilities.</p> <p>The failed request leaves an orphaned agent action according to proc</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># lfs path2fid /mnt/lustre/Asterix [0x200000400:0x1:0x0] # cat /proc/fs/lustre/mdt/lustre-MDT0000/hsm/agent_actions lrh=[type=10680000 len=136 idx=73] fid=[0x200000400:0x1:0x0] dfid=[0x200000400:0x1:0x0] compound/cookie=0x52150414/0x52150414 action=ARCHIVE archive#=0 flags=0x0 extent=0x0-0xffffffffffffffff gid=0x0 datalen=0 status=WAITING data=[] </pre> </div></div> <p>Similarly a non-root user cannot archive any files.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># cd /mnt/lustre # mkdir sanity # chown sanity: sanity # cd sanity # su sanity $ dd if=/dev/zero of=Obelix bs=1M count=50 $ ls -l Obelix -rw-rw-r-- 1 sanity sanity 52428800 Aug 21 14:03 Obelix $ lfs hsm_archive Obelix $ echo $? 0 $ sleep 60 $ lfs hsm_state Obelix Obelix: (0x00000000) </pre> </div></div> LU-3811

non-root users cannot archive files, root cannot archive non-root users' files

Technical task LU-3647 Blocker Closed Fixed Jinshan Xiong John Hammond HB HSM Wed, 21 Aug 2013 19:07:27 +0000 Mon, 21 Oct 2013 22:23:54 +0000 Wed, 4 Sep 2013 13:49:56 +0000 Lustre 2.5.0 Lustre 2.5.0 0 9 <p>good catch. For command line tool, only the root can archive and release files; normal users should be able to restore their own files, by either `lfs hsm_restore' or directly access.</p> <p>IMO there is no reason to distinguish explicit request (through cmd line) from implicit request. Also archive/restore must be doable by user. One use case is in a job epilog, the user archive all the data produced by the run. In any case there is no security issue, the only issue is the interaction with quotas which is an open pb. For me, inforced quotas are incompatible with HSM.</p> <p>I think there are two problems here:</p> <ul class="alternate" type="square"> <li>the volatile files created should use the uid/gid of the creating process for the new file, as with any regular file create</li> <li>the root copytool should chown/chmod the file to the correct ownership before trying to swap the layout</li> </ul> <p>Andreas, indeed.</p> <p>Supporting HSM archive by normal users requires raising the capabilities of the coordinator which we need to do anyway. Then we have there is the issue that an unprivileged user may archive files they don't own.</p> <p>Should normal users be allowed to release their own files? If so then there is also the problem that, as implemented, HSM release requires that the user possess create privileges in the MDT's local root.</p> <p>I believe that we all agree that implicit restore should be handled transparently. This can be fixed in the copytool. What about explicit restore? There are some weak security issues here, since user space can just give an arbitrary FID to llite.</p> <p>On the permissions question, I think this is policy and so should be deferred to the site admins, via proc tunables (yucky but whatever) or a setuid() binary (less yucky but not something we usually do). </p> <blockquote> <p>IMO there is no reason to distinguish explicit request (through cmd line) from implicit request. Also archive/restore must be doable by user. One use case is in a job epilog, the user archive all the data produced by the run. In any case there is no security issue, the only issue is the interaction with quotas which is an open pb. For me, inforced quotas are incompatible with HSM.</p></blockquote> <p>I tend to think we need to distinguish request from command line and policy engine. Archive and release should be a privileged operation because it will consume system resources. Otherwise, the system may be easily DoS attack by malicious users. This is the usual case for similar kind of product.</p> <p>For epilog cases, I think we should do some work on policy engine so that it can be picked.</p> <p>Please see <a href="http://review.whamcloud.com/7461" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7461</a>.</p> <ul class="alternate" type="square"> <li>the volatile files created should use the uid/gid of the creating process for the new file, as with any regular file create<br/> so it will not be possible to restore a file in a RO directory. there is no reason for such restriction </li> </ul> <p>Also note that there is not enough permission checking in mdt_hsm_request() and friends. A non-root user can cancel HSM requests, do hsm_remove, ...</p> <blockquote><p>Archive and release should be a privileged operation because it will consume system resources.</p></blockquote> <p>Release is not really resource consuming, it is resource freeing (it is a way for the user to do a kind of posix_fadvise(DONTNEED) with HSM meaning).</p> <p>I'd rather say restore is the more resource consuming (use Lustre disk space + copy bandwidth + tape drive). And archive, that use copy bandwidth.</p> <blockquote><p>Otherwise, the system may be easily DoS attack by malicious users.</p></blockquote> <p>A DoS is still easy on a HSM system by restoring all readable files.<br/> For archive and restore, it is more a QoS issue to avoid a single user to get all the bandwidth.</p> <blockquote><p>A non-root user can cancel HSM requests, do hsm_remove, ...</p></blockquote> <p>Indeed, this is dangerous...</p> <blockquote> <p>Release is not really resource consuming, it is resource freeing (it is a way for the user to do a kind of posix_fadvise(DONTNEED) with HSM meaning).</p></blockquote> <p>thinking about a case that an archive already exists so the malicious user can keep releasing and restoring a file in an infinite loop.</p> <p>I though it best to restart the permissions debate in a net ticket. Please see <a href="https://jira.whamcloud.com/browse/LU-3866" title="missing permission checks on HSM operations" class="issue-link" data-issue-key="LU-3866"><del>LU-3866</del></a>.</p> <p>Patch landed to master.</p> Duplicate LU-3825 Related LU-3866 Development Rank 1|hzvyuf: Rank (Obsolete) 9850