[LU-784] Cannot access named pipes or sockets with Posix-ACLs Created: 21/Oct/11  Updated: 16/Jan/13  Resolved: 24/Oct/12

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 1.8.6
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Daniel Kobras (Inactive) Assignee: Sarah Liu
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

Tested on live systems with Lustre 1.8.5, RHEL4 and RHEL5 clients. Problem could be trivially reproduced in a VM running CentOS5 with Lustre 1.8.6-wc1.


Issue Links:
Duplicate
duplicates LU-2518 Corrupted files Resolved
Severity: 3
Rank (Obsolete): 6538

 Description   

Named pipes (FIFOs) and sockets in a Lustre filesystem can no longer be
accessed or unlinked if Posix-ACLs are set. This can be easily reproduced:

% mknod /lustre/test.pipe p
% setfacl -m g:testgroup:rx /lustre/test.pipe

Subsequently, all of the following operations result in EOPNOTSUPP, leaving an
inode that cannot be removed.

% stat /lustre/test.pipe
% unlink /lustre/test.pipe
% setfacl -b /lustre/test.pipe
% setfattr -x system.posix_acl_access testpipe
% getfacl /lustre/test.pipe
% getfattr -m '.*' /lustre/test.pipe

For each of these commands, syslog lists an error message like:

LustreError: 28069:0:(mdc_request.c:489:mdc_unpack_acl()) convert xattr to acl: -95

The ACLs on the test file work fine with getfacl when mounting the MDT as
ldiskfs, so they are stored correctly. Looking at mdc_unpack_acl() and
posix_acl_from_xattr(), the EOPNOTSUPP means they get garbled when they're
read back and sent to the client, though.



 Comments   
Comment by Peter Jones [ 21/Oct/11 ]

Daniel

To be clear - is this a regression from 1.8.5 or is this same behaviour also seen in 1.8.5? I am clear that it manifests in 1.8.6-wc1.

Thanks

Peter

Comment by Peter Jones [ 23/Oct/11 ]

Sarah

Could you please try and reproduce this?

Thanks

Peter

Comment by Daniel Kobras (Inactive) [ 24/Oct/11 ]

Sorry, bad wording: The problem occurs in (at least) 1.8.5 and 1.8.6-wc1. I haven't tested with any other Lustre version.

Comment by Peter Jones [ 24/Oct/11 ]

Thanks for clarifying Daniel.

Comment by Sarah Liu [ 24/Oct/12 ]

I tried this on 2.3.0, both server and client are RHEL6, cannot reproduce it.

root@client-4 ~]# mount
/dev/sda1 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
fat-amd-1@tcp:/lustre on /mnt/lustre type lustre (rw,user_xattr,acl,flock)
[root@client-4 ~]# rpm -qa|grep lustre
lustre-client-modules-2.3.0-2.6.32_279.5.1.el6.x86_64.x86_64
lustre-client-2.3.0-2.6.32_279.5.1.el6.x86_64.x86_64
lustre-client-tests-2.3.0-2.6.32_279.5.1.el6.x86_64.x86_64
[root@client-4 ~]# 
[root@client-4 ~]# mknod /mnt/lustre/test.pipe p
[root@client-4 ~]# setfacl -m g:quota_usr:rx /mnt/lustre/test.pipe 
[root@client-4 ~]# stat /mnt/lustre/test.pipe 
  File: `/mnt/lustre/test.pipe'
  Size: 0         	Blocks: 0          IO Block: 4096   fifo
Device: 2c54f966h/743766374d	Inode: 144115205255725060  Links: 1
Access: (0654/prw-r-xr--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-10-24 13:52:38.000000000 -0700
Modify: 2012-10-24 13:52:38.000000000 -0700
Change: 2012-10-24 13:52:58.000000000 -0700
[root@client-4 ~]# unlink /mnt/lustre/test.pipe 
[root@client-4 ~]# mknod /mnt/lustre/test.pipe p
[root@client-4 ~]# setfacl -m g:quota_usr:rx /mnt/lustre/test.pipe 
[root@client-4 ~]# setfacl -b /mnt/lustre/test.pipe 
[root@client-4 ~]# setfattr -x system.posix_acl_access /mnt/lustre/test.pipe 
[root@client-4 ~]# getfacl /mnt/lustre/test.pipe 
getfacl: Removing leading '/' from absolute path names
# file: mnt/lustre/test.pipe
# owner: root
# group: root
user::rw-
group::r--
other::r--

[root@client-4 ~]# getfattr -m '.*' /mnt/lustre/test.pipe 
getfattr: Removing leading '/' from absolute path names
# file: mnt/lustre/test.pipe
trusted.link
trusted.lma

[root@client-4 ~]# 

While on 1.8.6-wc1, it can be reproduced:

[root@client-4 ~]# stat /mnt/lustre/test.pipe 
LustreError: 3751:0:(mdc_request.c:489:mdc_unpack_acl()) convert xattr to acl: -95
stat: cannot stat `/mnt/lustre/test.pipe': Operation not supported
[root@client-4 ~]# rpm -qa|grep lustre
lustre-client-1.8.6-wc1_2.6.18_238.12.1.el5
lustre-client-modules-1.8.6-wc1_2.6.18_238.12.1.el5
lustre-client-tests-1.8.6-wc1_2.6.18_238.12.1.el5
[root@client-4 ~]# 
[root@client-4 ~]# mount
/dev/sda1 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
fat-amd-1@tcp:/lustre on /mnt/lustre type lustre (rw,user_xattr,acl,flock)

I am going to try it on 1.8.8 and will keep you updated.

Comment by Sarah Liu [ 24/Oct/12 ]

1.8.8 also has this issue, I tested with both server and client running RHEL5

[root@client-4 ~]# mknod /mnt/lustre/test.pipe p
[root@client-4 ~]# setfacl -m g:quota_usr:rx /mnt/lustre/test.pipe
[root@client-4 ~]# stat /mnt/lustre/teLustreError: 3525:0:(mdc_request.c:489:mdc_unpack_acl()) convert xattr to acl: -95
st.pipe
LustreError: 3671:0:(mdc_request.c:489:mdc_unpack_acl()) convert xattr to acl: -95
stat: cannot stat `/mnt/lustre/test.pipe': Operation not supported
[root@client-4 ~]# rpm -qa|grep lustre
lustre-client-1.8.8-wc1_2.6.18_308.4.1.el5_gbc88c4c
lustre-client-modules-1.8.8-wc1_2.6.18_308.4.1.el5_gbc88c4c
lustre-client-tests-1.8.8-wc1_2.6.18_308.4.1.el5_gbc88c4c

Comment by Peter Jones [ 24/Oct/12 ]

Thanks Sarah! Daniel, if you have not already it sounds like upgrading to a more current release is the way forward

Generated at Sat Feb 10 01:10:22 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.