[LU-9929] Use "setfacl" to set "default" setting fail when nodemap enabled

• Type: Bug
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.11.0, Lustre 2.10.2
• Environment: Lustre 2.9
• Severity: 3
• Assignee: Emoly Liu
• Reporter: sebg-crd-pm (Inactive)

Description

Hi ,

When we setfacl default in lustre directory, I got unmapping group id(getfacl) after first setting(setfacl) . Then we executed setfacl command again and got fail ( Operation not permitted).

Please help us to fix this problem. Thanks!

The detail information is listed below.

1.cat /etc/passwd
user1:x:1001:1001::/home/user1:/bin/bash
2.nodemap setting
nodemap.21b7e9f04fed448e.idmap=
[
.....

{ idtype: gid, client_id: 1001, fs_id: 23501 }

,
.....
]
3.setfacl steps
[root@hsm client]# mkdir hadoop3
[root@hsm client]# getfacl /mnt/client/hadoop3
getfacl: Removing leading '/' from absolute path names
file: mnt/client/hadoop3
owner: root
group: root
user::rwx
group::r-x
other::r-x
[root@hsm client]# setfacl -R -d -m group:user1:rwx /mnt/client/hadoop3
[root@hsm client]# getfacl /mnt/client/hadoop3
getfacl: Removing leading '/' from absolute path names
file: mnt/client/hadoop3
owner: root
group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:23501:rwx
default:mask::rwx
default:other::r-x
[root@hsm client]# setfacl -R -d -m group:user1:rwx /mnt/client/hadoop3
setfacl: /mnt/client/hadoop3: Operation not permitted

Issue Links

• duplicates: LU-9759 setfacl default setting fail when nodemap enabled

Comments

[Gerrit Updater]

John L. Hammond ([e-mail]) merged in patch https://review.whamcloud.com/29369/
Subject: LU-9929 nodemap: add default ACL unmapping handling
Project: fs/lustre-release
Branch: b2_10
Current Patch Set:
Commit: 2ee62fbbf14e055d0134eb0859999be394909f8f

[Gerrit Updater]

Minh Diep ([e-mail]) uploaded a new patch: https://review.whamcloud.com/29369
Subject: LU-9929 nodemap: add default ACL unmapping handling
Project: fs/lustre-release
Branch: b2_10
Current Patch Set: 1
Commit: 6b798de0455d056d77ac5570187d3f550be52210

[Peter Jones]

Landed for 2.11

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/29010/
Subject: LU-9929 nodemap: add default ACL unmapping handling
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 62fee20556a4c90361bd28edb903dc77c9540133

[Gerrit Updater]

Emoly Liu ([e-mail]) uploaded a new patch: https://review.whamcloud.com/29010
Subject: LU-9929 nodemap: add unmapping process for default ACLs
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 0c7cc39d930d7ac7b2b0614d623103c5caddb2e6

[Emoly Liu]

When acl default unmapping code is added to mdt_getxattr(), EPERM issue disappears too.

The issue happened because after the first setfacl, a wrong default acl was cached in the client side, when running setfacl again, FS didn't know this wrong unmapped gid(23501), so treated it as a squash id, then this squash id entry(8 bytes) was skipped in nodemap_map_acl(). That's why we saw EPERM error.

I will submit a patch later.

[Emoly Liu]

Hi sebg-crd-pm,
As you said, there are two issues:

• wrong mapping gid(getfacl): according to my following debugging information, the second tree_type should be 0 (NODEMAP_FS_TO_CLIENT) instead. This should be fixed soon.

  Sep 13 15:03:02 centos7-2 kernel: id=1001, id_type=1, tree_type=1
  Sep 13 15:03:02 centos7-2 kernel: id=23501, id_type=1, tree_type=1
  
  

• EPERM(setfacl): the diff 52-44=8 bytes is caused by the acl entry whose nm_squash_id is 99. I still need some time to investigate where this squash id(99) comes from and why it needs to be skipped, and if we skip this check, why it returns EINVAL instead from ldiskfs.

I will give a update later.

[sebg-crd-pm (Inactive)]

Hi Emoly,

Do you have any update ?

Thanks!

[Emoly Liu]

The following log

00000004:00000001:2.0:1504689607.481641:0:22011:0:(mdt_xattr.c:327:mdt_reint_setxattr()) Process leaving via out (rc=18446744073709551615 : -1 : 0xffffffffffffffff)

shows the error comes from the following code

int mdt_reint_setxattr() {
...
                rc = nodemap_map_acl(nodemap, rr->rr_eadata, xattr_len,
                                     NODEMAP_CLIENT_TO_FS);
                nodemap_putref(nodemap);
                if (rc < 0)
                        GOTO(out, rc);

                /* ACLs were mapped out, return an error so the user knows */
                if (rc != xattr_len)
                        GOTO(out, rc = -EPERM);
...
}

The debugging information shows rc(44) != xattr_len(52). I will see what's wrong here.

[Emoly Liu]

Thanks, I can see this issue now. I will investigate it.