[LU-532] 2.1 does not filter extended attributes list based on permissions, showing entire list at all times Created: 25/Jul/11 Updated: 08/Sep/15 Resolved: 24/May/12 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.1.0, Lustre 2.2.0, Lustre 2.3.0, Lustre 2.1.2 |
| Fix Version/s: | Lustre 2.3.0, Lustre 2.1.2 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Lukasz Flis | Assignee: | nasf (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Client: lustre 1.8.6-wc1 |
||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 4610 | ||||||||
| Description |
|
There seems to be a problem with user_xattr when using 1.8.6-wc1 client with cd /mnt/lustre/scratch/people/b14flis mv test /tmp mv: getting attribute `trusted.lma' of `trusted.lma': Operation not permitted strace dump: serwer side error: Lustre: 10440:0:(mdt_xattr.c:374:mdt_reint_setxattr()) client miss to set OBD_MD_FLCTIME when setxattr: [object [0x2002f0053:0x38:0x0]] [valid 68719476736] mount options: Client: We can supply more information if needed. – |
| Comments |
| Comment by Andreas Dilger [ 25/Jul/11 ] |
|
Is this test being run ad a regular user or as root? For regular users, the "trusted.*" xattrs are inaccessible. The server side error is definitely incorrect (though useful). It is legal (though unusual) for clients not to send timestamps with the RPCs, but that means the server timestamps will be used. The client should send the ctime with the setxattr, since we normally use the client timestamps for file updates to avoid clock-skew issues visible on the client. |
| Comment by Lukasz Flis [ 25/Jul/11 ] |
|
This test was done by regular user. The error message appears even when lustre is mounted w/o xattributes. We also have other Lustre filesystem mounted on the same machine but served via 1.8.6 servers and |
| Comment by Oleg Drokin [ 28/Jul/11 ] |
|
Ok, I think I tracked this one down. The problem in 2.1 is all permission checks are done at MDD level and wthe user info does not filter down to ldiskfs it seems, so the ldiskfs check does not work and all attributes are always present in listxattr output. Additionally I am not sure if we want to do filtering that we want to do it on server as opposed to the filtering on client so that the client can always cache the full list and save RPCs on subsequent access |
| Comment by Andreas Dilger [ 28/Jul/11 ] |
|
I think it makes more sense to do the xattr list filtering on the client, since it is possible that root will want to access all the xattrs on the client at some point (e.g. for backup). Moving discussion about xattr cache to a separate bug I've submitted http://review.whamcloud.com/1161 to improve the MDS-side warning message to make this problem easier to debug in the future. The 1.8 client should also needs a patch so that it sends OBD_MD_FLCTIME for setxattr - looks like mdc_xattr_common() is the right place for it. |
| Comment by Oleg Drokin [ 01/Aug/11 ] |
|
Updated the title to indicate this is not an interop issue. Lukasz, this does not affect the data integrity or anything similar, so I think it should not be a big area of concern for you at this time. |
| Comment by Build Master (Inactive) [ 31/Oct/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 31/Oct/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 01/Nov/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Andreas Dilger [ 05/Apr/12 ] |
|
This is still a problem for Lustre 2.3.0. Running sanity.sh test_102j() as a non-root user with a lustre-aware tar still shows lots of spurious errors: tar: d0.sanity/d102: Warning: Cannot fgetxattr: Operation not permitted tar: d0.sanity/d102: Warning: Cannot fgetxattr: Operation not permitted tar: d0.sanity/d102: Warning: Cannot fgetxattr: Operation not permitted tar: d0.sanity/d102/file3-1-1: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file3-1-1: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file3-1-1: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file3-0-2: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file3-0-2: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file3-0-2: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file1-0-1: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file1-0-1: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file1-0-1: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file1-1-3: Warning: Cannot lgetxattr: Operation not permitted tar: d0.sanity/d102/file1-1-3: Warning: Cannot lgetxattr: Operation not permitted Running this under strace shows it trying to access the trusted xattrs: lgetxattr("d0.sanity/d102/file2-1-1", "trusted.lma", 0x229d690, 1024) = -1 EPERM (Operation not permitted)
lgetxattr("d0.sanity/d102/file2-1-1", "trusted.link", 0x229d690, 1024) = -1 EPERM (Operation not permitted)
lgetxattr("d0.sanity/d102/file2-1-1", "trusted.lov", 0x229d690, 1024) = -1 EPERM (Operation not permitted)
This would essentially make the RHEL6 tar unusable on a 2.x client, so I'm elevating it to blocker status for 2.1.2 and 2.3. |
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by nasf (Inactive) [ 09/Apr/12 ] |
|
Patch for filtering out trusted. xattr for non-root users: |
| Comment by Peter Jones [ 24/May/12 ] |
|
Landed for 2.1.2 and 2.3 |
| Comment by Wojciech Turek (Inactive) [ 30/Aug/12 ] |
|
I am still seeing these when moving a file as an ordinary user. I am using 2.1.2 server and 1.8.8 client mv test0000 /scratch/mb435/ On the server log shows Aug 30 12:34:40 10.143.245.207 mds07 kernel: Lustre: 5499:0:(mdt_xattr.c:377:mdt_reint_setxattr()) lhome-MDT0000: client miss to set OBD_MD_FLCTIME when setxattr system.posix_acl_access: [object [0x200000bf7:0x9b:0x0]] [valid 68719476736] |
| Comment by Andreas Dilger [ 05/Sep/12 ] |
|
Filed |