From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
"P. Berrange, Daniel" <berrange@redhat.com>,
qemu-devel@nongnu.org, vgoyal@redhat.com
Subject: Re: libcap vs libcap-ng mess
Date: Mon, 2 Dec 2019 10:07:31 +0000 [thread overview]
Message-ID: <20191202100731.GB2904@work-vm> (raw)
In-Reply-To: <CABgObfZjz=5vWs+-DHTaxfOEu+9Vw1+SuZLSpzxZpRNFRzNKEQ@mail.gmail.com>
* Paolo Bonzini (pbonzini@redhat.com) wrote:
> Il ven 29 nov 2019, 19:54 Dr. David Alan Gilbert <dgilbert@redhat.com> ha
> scritto:
>
> > > Yes, it's per thread. The state can be built from
> > > capng_clear/capng_get_caps_process + capng_update, and left in there
> > > forever. There is also capng_save_state/capng_restore_state which, as
> > > far as I can see from the sources, can be used across threads.
> >
> > So, I think what you're saying is I need to:
> > a) Before we sandbox do the capng_get_caps_process
> >
>
> Why not after sandboxing?
Because in our sandbox we don't have /proc and capng_get_caps_process
tries to read /proc/.../status and fails. The old libcap code doesn't
use /proc, it just uses capget (which the new one also uses).
> If the code is in any way similar to the 9p
> proxy, you have two states, "sandboxed with capabilities" and "sandboxed
> without capabilities". The former (permitted=effective) is what you get
> after setresuid/setresgid, the other can be computed after sandboxing and
> saved using capng_save_state. The FSETID capability can be updated
> explicitly before/after capng_apply.
>
> b) Before we start a new thread do a capng_save_state and restore it
> > in the thread
> >
>
> Or just save after (a), and restore always before capng_apply.
Hmm yes, that's easier.
> a) This code is very local - it does a drop FSETID, a write, restore
> > FSETID
> > b) I'm not sure but I suspect it's used only in the non-uid=0 case;
> > the whole thing is just a hack to cause setuid/setgid to be dropped
> > in the case where it's written by a process that doesn't have FSETID
> > (hmm I guess if the guest was root but didn't have fsetid then it would
> > be 0?)
> >
>
> Yes it would. For uid!=0 the kernel clears the effective capabilities so it
> shouldn't need to do anything, unless virtiodsd restores capabilities after
> setresuid/setresgid.
>
> But are you suggesting I need to change something other than the
> > effective caps in that case?
> >
>
> No, only the effective caps.
OK, thanks.
Dave
> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-12-02 10:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-28 19:04 libcap vs libcap-ng mess Dr. David Alan Gilbert
2019-11-29 9:34 ` Daniel P. Berrangé
2019-11-29 10:46 ` Paolo Bonzini
2019-11-29 10:51 ` Dr. David Alan Gilbert
2019-11-29 18:01 ` Dr. David Alan Gilbert
2019-11-29 18:12 ` Paolo Bonzini
2019-11-29 18:20 ` Dr. David Alan Gilbert
2019-11-29 18:27 ` Paolo Bonzini
2019-11-29 18:54 ` Dr. David Alan Gilbert
2019-11-29 23:19 ` Paolo Bonzini
2019-12-02 10:07 ` Dr. David Alan Gilbert [this message]
2019-12-02 10:33 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191202100731.GB2904@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).