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-1532 Lustre <p><span class="error">&#91;sanity@r62-lustre lustre&#93;</span>$ echo 'Achievement unlocked.' &gt; .lustre/fid/<span class="error">&#91;0xc:0x0:0x0&#93;</span>/SANITY<br/> <span class="error">&#91;sanity@r62-lustre lustre&#93;</span>$ stat .lustre/fid/<span class="error">&#91;0xc:0x0:0x0&#93;</span>/SANITY<br/> File: `.lustre/fid/<span class="error">&#91;0xc:0x0:0x0&#93;</span>/SANITY'<br/> Size: 22 Blocks: 1 IO Block: 2097152 regular file<br/> Device: 2c54f966h/743766374d Inode: 144115205255725057 Links: 1<br/> Access: (0664/<del>rw-rw-r</del>-) Uid: ( 500/ sanity) Gid: ( 500/ sanity)<br/> Access: 2012-06-15 15:06:07.000000000 -0500<br/> Modify: 2012-06-15 15:06:05.000000000 -0500<br/> Change: 2012-06-15 15:06:05.000000000 -0500<br/> <span class="error">&#91;sanity@r62-lustre lustre&#93;</span>$ cat .lustre/fid/<span class="error">&#91;0xc:0x0:0x0&#93;</span>/SANITY<br/> Achievement unlocked.</p> <p><span class="error">&#91;root@r62-lustre lustre-release&#93;</span># debugfs /dev/loop0<br/> debugfs 1.41.90.wc4 (01-Sep-2011)<br/> debugfs: ls CONFIGS<br/> 12 (12) . 2 (12) .. 13 (20) mountdata 15 (20) _mgs-sptlrpc <br/> 16 (24) lustre-client 17 (24) lustre-sptlrpc 18 (24) lustre-MDT0000 <br/> 19 (24) lustre-params 21 (28) changelog_catalog <br/> 22 (44) changelog_users 93 (16) sptlrpc 95 (24) lustre-OST0000 <br/> 96 (24) lustre-OST0001 100 (3800) SANITY </p> <p><span class="error">&#91;sanity@r62-lustre lustre&#93;</span>$ rm .lustre/fid/<span class="error">&#91;0xc:0x0:0x0&#93;</span>/mountdata</p> <p>Message from syslogd@r62-lustre at Jun 15 15:09:26 ...<br/> kernel:LustreError: 2858:0:(osd_internal.h:665:osd_fid2oi()) ASSERTION( !fid_is_igif(fid) ) failed: </p> <p>Message from syslogd@r62-lustre at Jun 15 15:09:26 ...<br/> kernel:LustreError: 2858:0:(osd_internal.h:665:osd_fid2oi()) LBUG</p> # uname -r<br/> 2.6.32-220.13.1.el6.l22.x86_64<br/> # cat /proc/fs/lustre/version <br/> lustre: 2.2.55<br/> kernel: patchless_client<br/> build: 2.2.55--CHANGED-2.6.32-220.13.1.el6.l22.x86_64<br/> LU-1532

only allow FID_SEQ_NORMAL from clients

Bug Blocker Resolved Fixed Mikhail Pershin John Hammond fid server Fri, 15 Jun 2012 16:14:04 +0000 Tue, 29 Apr 2014 20:13:32 +0000 Mon, 12 Nov 2012 18:31:25 +0000 Lustre 2.4.0 Lustre 2.1.4 0 5 <p>The osd_fid2oi() side effect is being fixed under <a href="https://jira.whamcloud.com/browse/LU-1534" title="Test failure on test suite lfsck" class="issue-link" data-issue-key="LU-1534"><del>LU-1534</del></a>.</p> <p>Mike</p> <p>Could you please look at this patch?</p> <p>Thanks</p> <p>Peter</p> <p>Hi Peter, Mike,</p> <p>Sorry I haven't had time to upload a patch on this one. For newly created filesystems it may be as simple as changing the mode to 0755 when CONFIGS is created, but I haven't tried to see if this would have any unwanted side-effects. For existing filesystems, a manual chmod may be the best solution.</p> <p>Note also that this issue applies to the OBJECTS and NIDTBL_VERSIONS directories.</p> <p>John</p> <p>The patch for <a href="https://jira.whamcloud.com/browse/LU-1518" title="Missing/bad operations in mdd_{obf,dot_lustre}_obj_op causing LBUGs" class="issue-link" data-issue-key="LU-1518"><del>LU-1518</del></a> (<a href="http://review.whamcloud.com/3726" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/3726</a>) blocks client access to FID_SEQ_DOT_LUSTRE for specific operations in order to prevent specific files in the .lustre tree from being renamed or otherwise modified.</p> <p>However, there are still a number of problems that may arise from clients accessing files in other FID_SEQ ranges. A safer approach would be to allow client-&gt;MDT access to only specific FID_SEQ ranges, and only open up those ranges if/when there is a specific need to do so. That will make the MDT and OST "safe by default" instead of blocking problematic ranges of objects after the fact.</p> <p>A preliminary list of acceptable SEQ/FIDs for the MDT:</p> <ul class="alternate" type="square"> <li>"ROOT" (whatever specific FID it might be, as determined by MDT_GETSTATUS RPC and lookup-by-name)</li> <li>FID_SEQ_ECHO (for mds-survey echo_client testing?)</li> <li>FID_SEQ_IGIF..FID_SEQ_IGIF_MAX (only for filesystems that were upgraded from 1.8)</li> <li>FID_SEQ_DOT_LUSTRE (blocked for specific operations at a lower level)</li> <li>FID_SEQ_NORMAL</li> </ul> <p>The "ROOT" FID may have a variety of values (IGIF for 1.8 filesystems, one FID_SEQ_SPECIAL FID for new filesystems, FID_SEQ_NORMAL for filesystems upgraded by the Xyratex 2.x upgrade tool), so it should just be allowd regardless of what FID is actually in use. This can be instantiated by the reply from the MDT_GETSTATUS RPC, which is doing a lookup-by-name and should be able to bypass the by-FID sanity checks. Similarly, the FID_SEQ_IGIF range should only be allowed for upgraded 1.8 filesystems, otherwise it would allow access to any objects in the filesystem.</p> <p>I haven't thought of a good way to retroactively determine if the filesystem was newly formatted with 2.x vs. upgraded from 1.8 yet. One possibility is to set an OBD_COMPAT_IGIF flag in the last_rcvd file if the filesystem is upgraded from 1.8 (i.e. missing OBD_COMPAT_20) or if some lookup-by-name/OI Scrub finds an inode with an IGIF FID. Filesystems without OBD_COMPAT_IGIF set would refuse lookups by IGIF FIDs.</p> <p>There would have to be some delay in enforcing this restriction, since existing upgraded filesystems would not have it set and it might accidentally block IGIF lookups for previously-upgraded filesystems. Maybe the setting of OBD_COMPAT_IGIF could be added for 2.1.4/2.3/master, and enforcement only in master?</p> <p>Acceptable SEQ/FIDs for the OST:</p> <ul class="alternate" type="square"> <li>FID_SEQ_OST_MDT0 (for legacy OST objects)</li> <li>FID_SEQ_LLOG (do we still allow/need this for 2.4 OSTs?)</li> <li>FID_SEQ_ECHO (obdfilter-survey testing)</li> <li>FID_SEQ_IDIF..FID_SEQ_IDIF_MAX (for legacy OST objects)</li> <li>FID_SEQ_NORMAL (for FID-on-OST)</li> </ul> <p>Unlike the MDT, there is no need to block legacy FID_SEQ_OST_MDT0/FID_SEQ_IDIF objects from clients, since they cannot be used to access objects via a different FID namespace.</p> <p>This patch should fix this problem for the MDS: <a href="http://review.whamcloud.com/4255" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4255</a></p> <p>Fixed by patch for <a href="https://jira.whamcloud.com/browse/LU-1531" title="Accessing .lustre/fid/[0x1:0x0:0x0] triggers LBUG in osd_compat_objid_lookup()" class="issue-link" data-issue-key="LU-1531"><del>LU-1531</del></a>:<br/> <a href="http://review.whamcloud.com/4255" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4255</a></p> Duplicate LU-1549 Related LU-1518 LU-1552 Development Rank 1|hzv2yn: Rank (Obsolete) 3979 Severity Story Points 2.0