On Thu, Mar 28, 2013 at 12:47:25PM +0100, Michal Privoznik wrote: > On 28.03.2013 12:12, Daniel P. Berrange wrote: > > 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 > > > > Aah. On BSD they support just 'system' and 'user': > > http://svnweb.freebsd.org/base/head/sys/sys/extattr.h?revision=184413&view=markup > > Does it mean we should move from 'trusted' to 'system'? Or is > conditional prefix ('trusted' on linux, 'system' on BSD) sufficient? You're not able to use 'system.' from userspace. # setfattr -n user.eek -v bar foo # setfattr -n system.eek -v bar foo setfattr: foo: Operation not supported So 'user.' is the only option here for BSD. If we consider the (admittedly unlikely) possibility of an NFS server access by 2 libvirt clients one running Linux and one running BSD, we want compatibility. So this says to me that we should use 'user.' as the prefer everywhere. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list