On Fri, 07.11.14 15:43, WaLyong Cho (walyong....@samsung.com) wrote: > On 11/07/2014 09:35 AM, Lennart Poettering wrote: > > On Fri, 07.11.14 04:17, WaLyong Cho (walyong....@gmail.com) wrote: > > > >> SMACK64 > >> Used to make access control decisions. In almost all cases > >> the label given to a new filesystem object will be the label > >> of the process that created it. > >> SMACK64EXEC > >> The Smack label of a process that execs a program file with > >> this attribute set will run with this attribute's value. > > > > I am sorry, but I cannot parse this. > > > > "The smack label .... will run with this attribute's value"? smack > > labels "run"? That sentence makes no sense to me at all... > > > > Again, what kind of objects are SMACK64 and SMACK64EXEC applied to? > > files? processes? > > Sorry, I'm also confused. > OK, I asked some about this to my security friend. > And I add Casey Schaufler who the Author of smack. > I hope my below explain it not wrong. But if not, please point out. > > > Quoting the Wikipedia: > >In practice, a subject is usually a process or thread; objects are > >constructs such as files, directories, TCP/UDP ports, shared memory > >segments, IO devices etc. > > > In case of SMACK, subject is SMACK64EXEC and object is SMACK64. > Assume like this: /usr/bin/dbus-daemon has both label. SMACK64 is "foo" > and SMACK64EXEC is "bar". And current process (what will execute the > /usr/bin/dbus-daemon) has "foo" label. Let's assume the current > process
So, here you are talking about *files* that have the SMACK64EXEC and SMACK64 type labels, while the *process* only as one generic label type. With your patch you want to introduce SmackLabelExec= now. It's a label applied to a *process* however, not to a *file*, right? This appears incompatible to me: I mean, if a process only has one single generic label, and doesn't distuingish between SMACK64 and SMACK64EXEC type labels, why would you call the option SmackLabelExec= and not the more generic SmackLabel=? This really doesn't make sense to me. I have no understanding of SMACK, and I am not sure I want to understand it, and I figure I'd merge the patch regardless which name you pick for the option, but this is a bit too blatantly contradictory for me to completely ignore. Let my simplify my questions: a) Why would you call a setting that controls a label is written into /proc/$PID/attr/current SmackLabelExec= instead of just SmackLabel=? b) If SmackLabelExec= is appropriate (which it might well be, after all I really don't grok this), and SmackLabel= is a misnomer that would suggest that something different would happen than actually assumed, then what would an option by the name SmackLabel= for a service unit do differntly from one called SmackLabelExec? For both SELinux and AppArmor we now have simple options: SELinuxContext= and AppArmorProfile=. They only come in one flavour, and apply a label/profile to the process being executed and that's it. Why would SMACK be more complicated there so that SmackLabel= and SmackLabelExec= would even be a distinction? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel