Bug 1115533 - Attempt to start /bin/dbus-daemon --system --fork fails with Failed to drop capabilities: Operation not permitted
Attempt to start /bin/dbus-daemon --system --fork fails with Failed to drop c...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Daniel Walsh
Virtualization Bugs
:
Depends On:
Blocks: 1109938
  Show dependency treegraph
 
Reported: 2014-07-02 10:35 EDT by Jan Pazdziora
Modified: 2016-08-02 13:00 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-18 16:46:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
build & run script for fake library and dbus (133 bytes, application/x-shellscript)
2014-07-09 14:17 EDT, Marcel Wysocki
no flags Details
fake library (235 bytes, text/x-csrc)
2014-07-09 14:17 EDT, Marcel Wysocki
no flags Details

  None (edit)
Description Jan Pazdziora 2014-07-02 10:35:15 EDT
Description of problem:

Attempt to start /bin/dbus-daemon --system --fork in a container leaves no process running. Stracing the process shows message Failed to drop capabilities: Operation not permitted.

Version-Release number of selected component (if applicable):

3.10.0-123.el7.x86_64 on the host
docker-0.11.1-22.el7.x86_64 on the host
dbus-1.6.12-8.el7.x86_64 in the container

How reproducible:

Deterministic.

Steps to Reproduce:
1. Run strace -s 500 -f -o /tmp/dbus.strace /bin/dbus-daemon --system --fork
2. Check /tmp/dbus.strace

Actual results:

54    geteuid()                         = 0
54    capget({0 /* _LINUX_CAPABILITY_VERSION_??? */, 0}, NULL) = 0
54    gettid()                          = 54
54    prctl(PR_SET_KEEPCAPS, 1)         = 0
54    capset({_LINUX_CAPABILITY_VERSION_3, 54}, {CAP_SETGID|CAP_SETUID|CAP_AUDIT_WRITE, CAP_SETGID|CAP_SETUID|CAP_AUDIT_WRITE, 0}) = -1 EPERM (Operation not permitted)
54    epoll_ctl(3, EPOLL_CTL_DEL, 4, {0, {u32=0, u64=0}}) = 0
54    close(4)                          = 0
54    unlink("/var/run/dbus/system_bus_socket") = 0
54    unlink("/var/run/messagebus.pid") = 0
54    write(2, "Failed to start message bus: Failed to drop capabilities: Operation not permitted\n\n", 83) = 83
54    exit_group(1)                     = ?

The matching piece of source seems to be

      capng_clear (CAPNG_SELECT_BOTH);
      capng_update (CAPNG_ADD, CAPNG_EFFECTIVE | CAPNG_PERMITTED,
                    CAP_AUDIT_WRITE);
      rc = capng_change_id (uid, gid, CAPNG_DROP_SUPP_GRP);
      if (rc)
        {
          switch (rc) {
            default:
              dbus_set_error (error, DBUS_ERROR_FAILED,
                              "Failed to drop capabilities: %s\n",
                              _dbus_strerror (errno));
              break;

Expected results:

Dropping capabilities seems like an operation that should pass in a container.

Additional info:
Comment 1 Jan Pazdziora 2014-07-02 10:36:48 EDT
Or does it actually fail because CAP_AUDIT_WRITE is being added?
Comment 3 Marcel Wysocki 2014-07-09 13:22:43 EDT
+1 I am affected by this as well.
Trying to run FreeIPA in a docker container.
Comment 4 Marcel Wysocki 2014-07-09 14:17:08 EDT
Created attachment 916918 [details]
build & run script for fake library and dbus
Comment 5 Marcel Wysocki 2014-07-09 14:17:34 EDT
Created attachment 916919 [details]
fake library
Comment 6 Marcel Wysocki 2014-07-09 14:18:29 EDT
was able to get it working with the good old LD_PRELOAD script.
Test files attached
Comment 7 Daniel Walsh 2014-07-15 13:00:08 EDT
Docker just added support for --cap-add which you should be able to figure out which capability you are missing.  You should be able to drop caps but you might not have all of the caps you need.
Comment 8 Marcel Wysocki 2014-07-16 09:22:58 EDT
but using --cap-add will permanently add that capability to the container, which could be a security risk. :/
I was able to start the dbus-daemon without the capability and just faking the library calls for dbus-daemon.
Comment 9 Marcel Wysocki 2014-07-23 14:03:53 EDT
@dwalsh

I put something together, might interest you

http://maci0.wordpress.com/2014/07/23/run-systemd-in-an-unprivileged-docker-container/
Comment 10 Daniel Walsh 2014-07-23 14:32:59 EDT
Have you tried working with systemd-container?

BTW I just added back AUDIT_WRITE to docker-1.1.1-3.el7.x86_64
Comment 11 Jan Pazdziora 2014-07-24 10:36:46 EDT
For FreeIPA, I just run the dbus as dbus directly from systemd:

https://github.com/adelton/docker-freeipa/commit/7a66b011dde9c60d63cc493904b798347f5530d3

That avoids the critical part of the code.
Comment 12 Daniel Walsh 2014-08-13 12:22:52 EDT
Fixed in docker-1.1.2-8.el7.x86_64
Comment 13 Jan Pazdziora 2014-08-14 09:22:04 EDT
(In reply to Daniel Walsh from comment #12)
> Fixed in docker-1.1.2-8.el7.x86_64

Confirming that with this daemon, dbus-daemon process starts and is running.
Comment 15 errata-xmlrpc 2014-09-18 16:46:02 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1266.html

Note You need to log in before you can comment on or make changes to this bug.