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. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list