You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a setup where we use ZoL we decided to turn extended attributes off, since we encountered quite a lot of problems with it. (including what I suspect is also #2214)
However, when turning xattr off I noticed that extended attributes were still copied over when copying data from a dataset where extended attributes were enabled, to a dataset where extended attributes were disabled explicitely. It was still possible to set new extended attributes, while we explicitely turned this off.
It seems very easy to reproduce, this test was done on a clean CentOS 6.5 installation with ZOL 0.6.3. Something I also noticed is when setting xattr=off, the dataset was not remounted, and mount still showed xattr in the mount options.
[root@localhost /]# zpool create storage /dev/sda2
[root@localhost /]# zfs create storage/testing
[root@localhost /]# zfs set xattr=off storage/testing
[root@localhost /]# mount
/dev/sda1 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
storage on /storage type zfs (rw,xattr)
storage/testing on /storage/testing type zfs (rw,xattr)
[root@localhost /]# zfs unmount storage
[root@localhost /]# zfs mount storage
[root@localhost /]# zfs mount storage/testing
[root@localhost /]# mount
/dev/sda1 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
storage on /storage type zfs (rw,xattr)
storage/testing on /storage/testing type zfs (rw,noxattr)
[root@localhost testing]# touch /storage/testing/file
[root@localhost testing]# setfattr -n security.selinux -v test /storage/testing/file
[root@localhost testing]# getfattr -n security.selinux /storage/testing/file
getfattr: Removing leading '/' from absolute path names
# file: storage/testing/file
security.selinux="test"
I quickly looked how btrfs (and probably other file systems) handle this, and it is still possible to read extended attributes, if the file system is mounted with the option noxattr, but setting attributes will result in the error:
setfattr: file: Operation not permitted
However when using ZoL, xattr=off seems purely a cosmectical option, since it does not actually enforce that extended attributes are disabled.
The text was updated successfully, but these errors were encountered:
@johandorland Security attributes are always allowed. You'd get an error if you tried setting "user.whatever". AFAIK, this is how other native xattr-supporting filesystems work.
The "noxattr" mount option shown when mounting a ZFS file system with xattr=off is somewhat bogus and is arguably a bug because it's actually a valid (file system independent) mount option.
Xattr-supporting native file systems do, however, suppport the "user_xattr" and "nouser_xattr" mount options and I've got no idea whether those would work properly with ZoL.
As to your original problem, were you using xattr=sa? If so, and if you wound up with any corrupted SAs in your file system, the only way to fix it is to copy all the files to a brand new file system running on 0.6.3 which should have fixed the relevant SA bugs.
@dweeezil It seems that you are indeed right. I did not expect this behaviour, so I thought it was a bug of ZoL, but it seems that I was wrong and it is the expected behaviour.
And indeed as to my original problem we used xattr=sa. We solved the problem however by not using selinux anymore and it has been working fine ever since.
In a setup where we use ZoL we decided to turn extended attributes off, since we encountered quite a lot of problems with it. (including what I suspect is also #2214)
However, when turning xattr off I noticed that extended attributes were still copied over when copying data from a dataset where extended attributes were enabled, to a dataset where extended attributes were disabled explicitely. It was still possible to set new extended attributes, while we explicitely turned this off.
It seems very easy to reproduce, this test was done on a clean CentOS 6.5 installation with ZOL 0.6.3. Something I also noticed is when setting xattr=off, the dataset was not remounted, and mount still showed xattr in the mount options.
I quickly looked how btrfs (and probably other file systems) handle this, and it is still possible to read extended attributes, if the file system is mounted with the option noxattr, but setting attributes will result in the error:
However when using ZoL, xattr=off seems purely a cosmectical option, since it does not actually enforce that extended attributes are disabled.
The text was updated successfully, but these errors were encountered: