[systemd-devel] [PATCH v2 1/2] Smack - relabel directories and files created by systemd

Łukasz Stelmach l.stelmach at samsung.com
Wed Feb 19 07:24:43 PST 2014

It was <2014-02-19 śro 16:06>, when Lennart Poettering wrote:
> On Wed, 19.02.14 15:44, Łukasz Stelmach (l.stelmach at samsung.com) wrote:
>> > Also, please move the #ifdef HAVE_SMACK checks inside of this function
>> > and make it a NOP on non-SMACK builds. That way we only have one #ifdef
>> > check for this and not one for each invocation of the function. The
>> > compiler should be smart away to suppress the function if it empty.
>> I am not sure about that. If we want smack_relabel_in_dev() to return a
>> value and call it from label_fix()
>> --8<---------------cut here---------------start------------->8---
>> int label_fix(const char *path, bool ignore_enoent, bool ignore_erofs) {
>>         int r = 0;
>> #ifdef HAVE_SELINUX
>> [...]
>> #endif
>>         smack_relabel_in_dev(path);
>>         return r;
>> }
>> --8<---------------cut here---------------end--------------->8---
>> then it seems better to write
>> --8<---------------cut here---------------start------------->8---
>> #elif defined(HAVE_SMACK)
>>         r = smack_relabel_in_dev(path);
>> #endif
>> --8<---------------cut here---------------end--------------->8---
>> and be able to add support for a yet undetermined security framework
>> below assuming systemd can have support for only one fw compiled in. How
>> to have support for more than one security fw reasonably compiled in? (I
>> think this is the moment to create the pattern).
> Well, the other option is to simply place the smack relabelling code
> directly in label_fix(), which would map 1:1 what we do for selinux.

Not really because smack_relabel_in_dev() is called in a few other
places below too.

Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140219/14108913/attachment.pgp>

More information about the systemd-devel mailing list