Bug 10158

Summary:	Calls to setfacl under pseudo don't result in xattr being set on the file
Product:	[Yocto Project Subprojects] Pseudo	Reporter:	Joshua Lock <joshuagloe>
Component:	pseudo	Assignee:	Hongxu Jia <hongxu.jia>
Status:	VERIFIED WORKSFORME	QA Contact:	Juan Ramos <juan.fernandox.ramos.frayle>
Severity:	normal
Priority:	Medium+	CC:	jose.perez.carranza, randy.macleod, seebs, sgw, yp.pseudo.watcher, yp.watcher
Version:	unspecified
Target Milestone:	2.3
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Joshua Lock 2016-08-17 14:40:36 UTC

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

Comment 1 Joshua Lock 2016-08-18 20:25:29 UTC

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.

Comment 2 Seebs 2016-09-16 02:59:00 UTC

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.

Comment 3 Joshua Lock 2016-09-16 12:20:11 UTC

(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.

Comment 4 Juan Ramos 2016-11-25 23:45:58 UTC

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.