attr vs. getfattr

attr vs. getfattr

[Christian Kujau]

Hi,

I have an issue with extended attributes on this machine (Debian/stable, 
2.6.32-5-amd64). This box is slowly being moved towards fully SELinux 
enabled and apparently some files have been labelled with SELinux 
attributes:

---------
# ls -l vnstat.conf
-rw-r--r--. 2 root root 2890 Jan 15 04:05 vnstat.conf

# ls -lZ vnstat.conf
-rw-r--r--. 2 root root unconfined_u:object_r:etc_t:s0 2890 Jan 15 04:05 vnstat.conf
---------

OK. But when I actually want to see the attributes, this happens:

---------
# getfattr --dump vnstat.conf
---------

I.e. "nothing" is printed. I understand there's "attr" specifically for 
XFS filesystems and at least it displays that there *is* an attribute 
stored, but it cannot get its value:

---------
# attr -l vnstat.conf
Attribute "selinux" has a 31 byte value for vnstat.conf

# attr -g selinux vnstat.conf 
attr_get: No data available
Could not get "selinux" for vnstat.conf
---------

Now that I know the attribute's name, I try to use "getfattr" to display 
its value:

---------
# getfattr -n selinux vnstat.conf
vnstat.conf: selinux: Operation not supported

via strace:

getxattr("vnstat.conf", "selinux", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
---------

Can someone explain to me what's going on? The reason for all this that I 
actually want to remove the selinux attributes from some directories[0], 
but this isn't working either:

---------
# attr -r selinux vnstat.conf 
attr_remove: No data available
Could not remove "selinux" for vnstat.conf
---------

Tbh, I'm not too savvy with SELinux, but the system is in "permissive" 
mode, so it should not interfere:

---------
# getenforce
Permissive

# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/data       27G   25G  1.6G  95% /data

# grep /data /proc/mounts
/dev/mapper/data /data xfs rw,seclabel,nosuid,nodev,relatime,attr2,nobarrier,noquota 0 0
# grep /data /etc/mtab
/dev/mapper/data /data xfs rw,nosuid,nodev,nobarrier 0 0

# grep _XFS /boot/config-2.6.32-5-amd64 
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
# CONFIG_XFS_DEBUG is not set
---------

Anyone got an idea what's going on here/what I am missing?

Thanks,
Christian.

[0] Why? Because I want to rsync from a remote machine, where
    the files do NOT have SELinux attributes. In essence the same
    scenario as in https://bugzilla.redhat.com/show_bug.cgi?id=461486
-- 
BOFH excuse #359:

YOU HAVE AN I/O ERROR -> Incompetent Operator error

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: attr vs. getfattr

[Eric Sandeen]

On 6/7/12 7:26 AM, Christian Kujau wrote:
> Hi,
> 
> I have an issue with extended attributes on this machine (Debian/stable, 
> 2.6.32-5-amd64). This box is slowly being moved towards fully SELinux 
> enabled and apparently some files have been labelled with SELinux 
> attributes:
> 
> ---------
> # ls -l vnstat.conf
> -rw-r--r--. 2 root root 2890 Jan 15 04:05 vnstat.conf
> 
> # ls -lZ vnstat.conf
> -rw-r--r--. 2 root root unconfined_u:object_r:etc_t:s0 2890 Jan 15 04:05 vnstat.conf
> ---------
> 
> OK. But when I actually want to see the attributes, this happens:
> 
> ---------
> # getfattr --dump vnstat.conf
> ---------
> 
> I.e. "nothing" is printed. I understand there's "attr" specifically for 
> XFS filesystems and at least it displays that there *is* an attribute 
> stored, but it cannot get its value:

By default it's looking at the user namespace.  You want to look at security (or all) with -m:

[root@inode ~]# getfattr -m "^security\\." -d /sbin/modprobe
getfattr: Removing leading '/' from absolute path names
# file: sbin/modprobe
security.selinux="system_u:object_r:insmod_exec_t:s0"

[root@inode ~]# getfattr -m - -d /sbin/modprobe
getfattr: Removing leading '/' from absolute path names
# file: sbin/modprobe
security.selinux="system_u:object_r:insmod_exec_t:s0"

> ---------
> # attr -l vnstat.conf
> Attribute "selinux" has a 31 byte value for vnstat.conf
> 
> # attr -g selinux vnstat.conf 
> attr_get: No data available
> Could not get "selinux" for vnstat.conf

You need to tell it to use the security namespace w/ -S:

# attr -S -g selinux  /sbin/modprobe 
Attribute "selinux" had a 35 byte value for /sbin/modprobe:
system_u:object_r:insmod_exec_t:s0

> ---------
> 
> Now that I know the attribute's name, I try to use "getfattr" to display 
> its value:
> 
> ---------
> # getfattr -n selinux vnstat.conf
> vnstat.conf: selinux: Operation not supported

# getfattr -n security.selinux /sbin/modprobe
getfattr: Removing leading '/' from absolute path names
# file: sbin/modprobe
security.selinux="system_u:object_r:insmod_exec_t:s0"


> via strace:
> 
> getxattr("vnstat.conf", "selinux", 0x0, 0) = -1 EOPNOTSUPP (Operation not supported)
> ---------
> 
> Can someone explain to me what's going on? The reason for all this that I 
> actually want to remove the selinux attributes from some directories[0], 
> but this isn't working either:
> 
> ---------
> # attr -r selinux vnstat.conf 
> attr_remove: No data available
> Could not remove "selinux" for vnstat.conf
> ---------

# attr -S -r selinux vnstat.conf, I think, but I get permission denied.

> Tbh, I'm not too savvy with SELinux, but the system is in "permissive" 
> mode, so it should not interfere:
> 
> ---------
> # getenforce
> Permissive
> 
> # df -h .
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/mapper/data       27G   25G  1.6G  95% /data
> 
> # grep /data /proc/mounts
> /dev/mapper/data /data xfs rw,seclabel,nosuid,nodev,relatime,attr2,nobarrier,noquota 0 0
> # grep /data /etc/mtab
> /dev/mapper/data /data xfs rw,nosuid,nodev,nobarrier 0 0
> 
> # grep _XFS /boot/config-2.6.32-5-amd64 
> CONFIG_XFS_FS=m
> CONFIG_XFS_QUOTA=y
> CONFIG_XFS_POSIX_ACL=y
> CONFIG_XFS_RT=y
> # CONFIG_XFS_DEBUG is not set
> ---------
> 
> Anyone got an idea what's going on here/what I am missing?

A lot of manpage reading and intuition-following and namespace-remembering.  ;)

It is kind of messy.  :(

-Eric

> Thanks,
> Christian.
> 
> [0] Why? Because I want to rsync from a remote machine, where
>     the files do NOT have SELinux attributes. In essence the same
>     scenario as in https://bugzilla.redhat.com/show_bug.cgi?id=461486

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: attr vs. getfattr

[Christian Kujau]

On Thu, 7 Jun 2012 at 21:54, Eric Sandeen wrote:
> > I.e. "nothing" is printed. I understand there's "attr" specifically for 
> > XFS filesystems and at least it displays that there *is* an attribute 
> > stored, but it cannot get its value:
> 
> By default it's looking at the user namespace.  You want to look at security (or all) with -m:

Aaargh! Namespaces...yes, of course. Thanks for reminding me and sorry for 
the noise.

> A lot of manpage reading and intuition-following and namespace-remembering.  ;)

Will do!

C.
-- 
BOFH excuse #79:

Look, buddy:  Windows 3.1 IS A General Protection Fault.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: attr vs. getfattr

[Brian Candler]

On Thu, Jun 07, 2012 at 08:01:06PM -0700, Christian Kujau wrote:
> On Thu, 7 Jun 2012 at 21:54, Eric Sandeen wrote:
> > > I.e. "nothing" is printed. I understand there's "attr" specifically for 
> > > XFS filesystems and at least it displays that there *is* an attribute 
> > > stored, but it cannot get its value:
> > 
> > By default it's looking at the user namespace.  You want to look at security (or all) with -m:
> 
> Aaargh! Namespaces...yes, of course. Thanks for reminding me and sorry for 
> the noise.

I was recently bitten by this too, and I consider it a bug in the manpage.

       -d, --dump
           Dump  the  values  of all extended attributes associated with path‐
           name.

I'd say it's not unreasondable to read this and think that -d dumps *all*
extended attributes, because that's what it says.

Only if you read later do you find:

       -m pattern, --match=pattern
           Only include attributes with names matching the regular expression
           pattern.   The  default  value  for  pattern  is  "^user\\." ...

Regards,

Brian.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs