[libvirt] [PATCH] Fix a compilation problem with LXC drop capabilities

Ryota Ozaki ozaki.ryota at gmail.com
Tue Jun 2 02:15:58 UTC 2009


On Mon, Jun 1, 2009 at 6:24 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Fri, May 29, 2009 at 04:42:54PM -0500, Serge E. Hallyn wrote:
>> Quoting Ryota Ozaki (ozaki.ryota at gmail.com):
>> > On Fri, May 29, 2009 at 9:20 PM, Daniel Veillard <veillard at redhat.com> 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 :|
>




More information about the libvir-list mailing list