On Mon, Jun 1, 2009 at 6:24 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Fri, May 29, 2009 at 04:42:54PM -0500, Serge E. Hallyn wrote: >> Quoting Ryota Ozaki (ozaki.ryota@xxxxxxxxx): >> > On Fri, May 29, 2009 at 9:20 PM, Daniel Veillard <veillard@xxxxxxxxxx> wrote: >> >> Hmm, yeah but note that often userspace is out of date with respect to >> "recent" new kernel-related defines. I do a lot of testing on a rhel >> 5.3 partition with spanking-new kernels, so rare is the time that I >> don't have to do >> >> #ifndef PR_CAPBSET_DROP >> #define PR_CAPBSET_DROP 24 >> #endif >> >> and same for clone flags (CLONE_NEWIPC), securebits, capabilities, >> etc. >> >> So if the prctl(PR_CAPBSET_DROP) returns -ENOSYS then absolutely I >> agree, > > This makes sense as a way to deal with this problem, since it matches > what we already do with the various CLONE_XXX & MOUNT_XXX flags too. That convinces me too. > NB, in the not too distant future I'm going to submit code for making > the libvirtd daemon drop alot of its capabilities, including clearing > the bounding set to prevent inheritance by any child processes except > in required circumstances. For that I'll likely use libcap-ng so we > will be able to stop callin prctl() directly in the LXC driver. Oh, good. Will the new facility allow us to specify which capabilities to be dropped in a XML file or somewhere? Or the set of caps will be hard-coded? ozaki-r > > Regards, > Daniel > > [1] libcap-ng isn't technically yet announced to the world, but it'll > appear real soon... > -- > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| > -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list