[systemd-devel] [PATCH] bus-proxy: --clone-smack-label option
Lennart Poettering
lennart at poettering.net
Wed Nov 5 08:28:41 PST 2014
On Wed, 05.11.14 16:08, Przemyslaw Kedzierski (p.kedzierski at samsung.com) wrote:
> This patch adds a '--clone-smack-label' option to systemd-bus-proxyd.
> When dbus client connects to systemd-bus-proxyd through Unix domain socket
> and this option is enabled
> proxy takes client's smack label and sets for itself.
Why is this an option? Shouldn't this be the default behaviour?
> + if (arg_clone_smack_label) {
> +
> + if (!mac_smack_use()) {
> + log_warning("No SMACK found");
> + goto exit_clone_smack_label;
> + }
> +
> + if (!peersec) {
> + log_warning("Invalid SMACK label");
> + goto exit_clone_smack_label;
> + }
> +
> + r = have_effective_cap(CAP_MAC_ADMIN);
> + if (r <= 0) {
> + log_warning("No CAP_MAC_ADMIN capability");
> + goto exit_clone_smack_label;
> + }
Instead of checking the cap in userspace we should just try to update
the label right away and let the kernel decide whether it wants to
allow this or not...
> +
> @@ -33,3 +33,4 @@ int mac_smack_apply(const char *path, const char *label);
> int mac_smack_apply_fd(int fd, const char *label);
> int mac_smack_apply_ip_in_fd(int fd, const char *label);
> int mac_smack_apply_ip_out_fd(int fd, const char *label);
> +int mac_smack_set_current_label(char *label);
The selinux code has a code mac_selinux_get_our_label(). I figure we
should unify the naming scheme here...
I don't really like the word "current" in this context, since, well,
of course it's current, and we don't use the word "current" for any
other calls...
As a matter of fact I actually don't like the "our" bit in the
existing selinux call, since it's not clear why that's supposed to be
plural.
Maybe name the SMACK call:
int mac_smack_set_process_label(const char *label);
And then rename the the selinux call:
int mac_selinux_get_process_label(char **label);
(I'll make the selinux change, please just rename the SMACK call as
pointed out.)
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list