[systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[Lennart Poettering]

On Fri, 07.11.14 03:18, WaLyong Cho (walyong.cho at gmail.com) wrote:

> On 11/06/2014 11:54 PM, Lennart Poettering wrote:
> > On Tue, 04.11.14 17:35, WaLyong Cho (walyong.cho at samsung.com) wrote:
> > 
> >> In case of systemd has "_" label and run as root, if a service file
> >> has "User=" option and the command line file has a special SMACK label
> >> then systemd will fail to execute the command. Generally, SMACK label
> >> is ignored for the root. But if a service has a "User=" then systemd
> >> will call setresuid() in the child process. After then it no more
> >> root. So it should have some of executable label for the command. To
> >> set the SMACK64EXEC before the uid is changed introduce new
> >> SmackLabelExec option.
> > 
> > Hmm, I am not sure I like the abbreviation of this. Can't we just call
> > this "SmackLabel="?
> SmackLabel is already used as socket. Can we use that also here?

Well, sure. I mean, SmackLabel= on a socket unit applies to the socket,
and SmackLabel= on a service unit applies to the processes forked off,
that feels quite natural I think. Overloading the field in this way
appears to be quite appropriate to me in this case.

> By the way, I hope to discuss about the naming of the SMACK options.
> SmackLabel/SmackLabelIPIn/SmackLabelIPOut are. They are used in socket
> group. According to SMACK description,
> SMACK64/SMACK64EXEC/SMACK64MMAP/SMACK64TRANSMUTE/SMACK64IPIN/SMACK64IPOUT are
> the origin attribute name. I think using origin name is most make sense.
> If you agree, then in this case, SMACK64EXEC will be.

What precisely is the "SMACK64" label, and in which way does it differ
from "SMACK64EXEC"? The former is the xattr field on files, the latter
the "current" procfs file on processes?

What is SMACK64MMAP for? Does any of the other labels apply to
processes?

Naming things is always one of the most difficult problems in computer
science I guesss...

In general we try to not do unnecessary abbreviations, especially for
more exotic functionality. It's certainly a good idea to stay close to
the low-level concepts, but then again dropping components of a
low-level name doesn't sound too bad to me.

> > ifdeffing the include is unnecessary. YOu can just include it without
> > ifdef protectionn, there's nothing in it that we need to avoid pullin in.
>
> SELINUX/APPARMOR also use #ifdef. But can SMACK use without that?

Well, they import system headers, but smack-util.h is not a system
header, it's shipped in systemd itself...

Lennart

-- 
Lennart Poettering, Red Hat