Re: [libvirt] [PATCH v5 3/3] security_dac: Favour ACLs over chown()

On Thu, Mar 28, 2013 at 11:38:04AM +0100, Michal Privoznik wrote: > On 28.03.2013 10:46, Daniel P. Berrange wrote: >> On Thu, Mar 21, 2013 at 05:50:49PM +0100, Michal Privoznik wrote: >>> #define VIR_FROM_THIS VIR_FROM_SECURITY >>> #define SECURITY_DAC_NAME "dac" >>> +#define SECURITY_DAC_XATTR_OLD_ACL "trusted.libvirt.dac.oldACL" >>> +#define SECURITY_DAC_XATTR_OLD_OWNER "trusted.libvirt.dac.oldOwner" >>> +#define SECURITY_DAC_XATTR_REFCOUNT "trusted.libvirt.dac.refCount" >> >> IMHO we don't need the 'trusted.' prefix on these. >> >> Daniel >> > > An XATTR has to have a prefix. We can choose from several prefixes. > attr(5) says: > > Currently the security, system, trusted, and user extended attribute > classes are defined as described below. Additional classes may be > added in the future. > > security - should be used by kernel security modules, such as Security > Enhanced Linux. As long as libvirt doesn't provide kernel module, we > should not be polluting this prefix. > > system - used by the kernel to store system objects such as Access > Control Lists and Capabilities. Again, we are not kernel. > > trusted - visible and accessible only to processes that have the > CAP_SYS_ADMIN capability (the super user usually has this capability). > Attributes in this class are used to implement mechanisms in user > space (i.e., outside the kernel) which keep information in extended > attributes to which ordinary processes should not have access. > > Note, that the three above can be touched only by root (or > CAP_SYS_ADMIN'ed process). > > user - may be assigned to files and directories for storing arbitrary > additional information such as the mime type, character set or encoding > of a file. > > The user. can be manipulated by ordinary user. > > My rationale for not allowing ordinary user to play with our XATTRs is > to prevent them chowning to arbitrary user. Ok, that makes more sense now. I wonder how portable this list of prefixes is though - does anyone know if *BSD use the same conventions ? Daniel