Messages in this thread | | | Date | Fri, 15 Mar 2013 13:07:00 -0400 | From | Stephen Smalley <> | Subject | Re: lgetxattr()/getxattr() return different values on a file labelled with selinux disabled |
| |
On 03/15/2013 11:24 AM, Thomas COUDRAY wrote: > 2013/3/15 Stephen Smalley <sds@tycho.nsa.gov>: >> f is truly a regular file and not a symlink pointing to a regular file? > > f is a truly regular file. > >> before_t and after_t are both defined in the policy? > > Only before_t was defined in the policy.
If not defined in policy, then kernel should remap to unlabeled sid context.
> When I define after_t in the policy, both commands return the same > label (after_t). > But I wouldn't expect this to make a difference in the output of both > commands (as the only visible difference is lgetxattr() vs getxattr())
getxattr security.* results are supplied by the security module rather than the filesystem to allow the value to be canonicalized. But this should happen the same for lgetxattr and getxattr; those should only differ if the file is a symlink.
>> before_t and after_t are not type aliases of each other? > > They are not. > >> What are the credentials (capabilities and SELinux security >> context/permissions) of the process running the ls and getfattr commands? > > It has unconfined_u:unconfined_r:before_t label with before_t type. > Same as the file f. > The process has full SELinux rights on both command and file.
Did it run as root? Does it have :capability2 mac_override permission?
>> Any relevant messages from SELinux in dmesg output? > > No avc warnings in dmesg and audit.log. All looks good.
What about SELinux: messages? e.g. SELinux: Context ... is not valid (left unmapped).
| |