On Thu, 06.11.14 11:44, Przemyslaw Kedzierski (p.kedzier...@samsung.com) wrote:
> When dbus client connects to systemd-bus-proxyd through > Unix domain socket proxy takes client's smack label and sets for itself. > > It is done before and independent of dropping privileges. > > The reason of such soluton is fact that tests of access rights > performed by lsm may take place inside kernel, not only > in userspace of recipient of message. > > The bus-proxyd needs CAP_MAC_ADMIN to manipulate its label. > > In case of systemd running in system mode, CAP_MAC_ADMIN > should be added to CapabilityBoundingSet in service file of bus-proxyd. > > In case of systemd running in user mode ('systemd --user') > it can be achieved by addition > Capabilities=cap_mac_admin=i and SecureBits=keep-caps > to user@.service file > and setting cap_mac_admin+ei on bus-proxyd binary. Hmm, is this really the way this should work? I am a bit afraid of including these lines on systems without SMACK. I figure this part at least should be removed on non-SMACK builds, with m4 magic. > Signed-off-by: Przemyslaw Kedzierski <p.kedzier...@samsung.com> We don't use S-o-b btw. > (void) getpeercred(in_fd, &ucred); > (void) getpeersec(in_fd, &peersec); > + > + if (mac_smack_use()) { > + if (peersec) { > + > + r = mac_smack_set_process_label(peersec); > + if (r < 0) > + log_warning("Failed to set SMACK > label %s : %s", peersec, strerror(-r)); Your colleage at Samsung, WaLyong Cho just posted a patch that added a new call mac_smack_apply_pid() which is a superset of the mac_smack_set_process_label(). I kinda like mac_smack_apply_pid() better I must say, hence I'd love if we could get his patch in first, and you could then rework your patch on top of his? > + } else { > + log_warning("Invalid SMACK label"); > + } Please no {} on single-line if blocks. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel