| 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: Fri, 02 Nov 2007 10:07:14 +0100 From: Olaf Dietsche <olaf+list.linux-kernel@...fdietsche.de> To: casey@...aufler-ca.com Cc: Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] 2.6.23: Filesystem capabilities 0.17 Casey Schaufler <casey@...aufler-ca.com> writes: > --- Olaf Dietsche <olaf+list.linux-kernel@...fdietsche.de> wrote: > >> The bits are stored in a sparse file named /.capabilities in the >> directory of the mount point, where the corresponding executable >> lives. The inode number of the file is the index into this file. > > The old PlanG approach. It's the way that we did MAC labels in > Trix4. It has the wicked advantage of working across NFS without > anyone being the wiser. If you don't trust a NFS, you'll mount it nosuid anyway and then fscaps are disabled too. > It really causes trouble for backup utilities, however. Whatever implementation you choose, you will always have to modify your backup utilities or copy the attributes separately. > Trix6 (there wasn't really a Trix5) had xattrs > available and we found the switch well worth the investment. Extended attributes are a nice, clean concept, like micro kernels for example :-). But they have a cost, which shouldn't be ignored. Regards, Olaf. - 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