10158 2016-08-17 14:40:36 +0000 Calls to setfacl under pseudo don't result in xattr being set on the file 2016-11-25 23:45:58 +0000 1 1 6 Yocto Project Subprojects Pseudo pseudo unspecified x86 Multiple VERIFIED WORKSFORME Medium+ normal 2.3 1 joshuagloe hongxu.jia jose.perez.carranza randy.macleod seebs sgw yp.pseudo.watcher yp.watcher juan.fernandox.ramos.frayle --- --- No (bug/feature does not impact docs) oldest_to_newest 65263 0 joshuagloe 2016-08-17 14:40:36 +0000 Setting extended attributes (xattr) on files (i.e. with setfattr or setxattr() calls) works in latest pseudo, however calls to setfattr from i.e. a postinst (or even during do_install) don't modify the xattr on the file. [root@tethys xattrtest-1.0]# getfattr -d ../image/usr/share/xattrtest/xattrtest # file: ../image/usr/share/xattrtest/xattrtest user.oeqa="miccheck" [root@tethys xattrtest-1.0]# getfacl -d ../image/usr/share/xattrtest/xattrtest # file: ../image/usr/share/xattrtest/xattrtest # owner: root # group: root [root@tethys xattrtest-1.0]# setfacl -m u:bar:r-- ../image/usr/share/xattrtest/xattrtest [root@tethys xattrtest-1.0]# getfacl -d ../image/usr/share/xattrtest/xattrtest # file: ../image/usr/share/xattrtest/xattrtest # owner: root # group: root 65326 1 joshuagloe 2016-08-18 20:25:29 +0000 This may (or may not) be related to the special handling of system.posix_acl_access extended attributes in pseudo. The code in shared_setxattr() of ports/linux/xattr/pseudo_wrappers.c attempts to undo GNU tar's conversion of all permissions to POSIX ACL extended attributes and instead change those which are just standard POSIX permissions into a chmod call. 66236 2 seebs 2016-09-16 02:59:00 +0000 So, I tried this, and... I get the exact same behavior with or without pseudo. getfacl -d "displays the default access control list". However, if you just do plain "getfacl" on the file, it seems to show the expected behavior. 66242 3 joshuagloe 2016-09-16 12:20:11 +0000 (In reply to comment #2) > > However, if you just do plain "getfacl" on the file, it seems to show the > expected behavior. Ugh, you're dead right. Apologies for the noise. I must've been looking at the wrong manual. 68612 4 juan.fernandox.ramos.frayle 2016-11-25 23:45:58 +0000 tested in commit: 6c9f6b5f70ab3ee194b2c2c6f3bd462c994848fa I got this: sh-4.3# getfacl dmesg.txt # file: dmesg.txt # owner: root # group: disk user::rwx group::rwx other::--- Verified.