| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sat, 28 Oct 2006 17:48:45 +0200 From: "Wesley W. Terpstra" <wesley@...pstra.ca> To: linux-kernel@...r.kernel.org Subject: Extended attributes on symlinks --> EPERM ? Good evening! Setting extended attributes on symlinks is forbidden with EPERM. Certainly, if you follow the symlink, it can set the value on the destination file, but I want to set extended attributes on the symlink itself. Is this correct behaviour?: pumpkin:/backup/x# touch y pumpkin:/backup/x# ln -s y x pumpkin:/backup/x# setfattr -h -n user.key1 -v val1 y pumpkin:/backup/x# setfattr -h -n user.key2 -v val2 x setfattr: x: Operation not permitted This happens on linux-2.6.18 with ext3/xfs and backports of extended attributes to 2.4.20 with ext3. The same thing works with extended attributes on osx. I have no other platforms with extended attributes to compare against. It seems desirable to be able to store extended attributes on symlinks: meta-data can apply to anything. In fact, this is causing trouble with an rsync option that stores ownership, device number, and mode in an extended attribute. This would allow backups to a root- less rsync server which uses no special file-system permissions in backing up client computers. Please CC me on replies. Thank you for your time! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists