From: mgrepl@redhat.com (Miroslav Grepl)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] systemd policy
Date: Mon, 27 Jan 2014 15:17:32 +0100 [thread overview]
Message-ID: <52E66A7C.4050001@redhat.com> (raw)
In-Reply-To: <52D53CF9.8030900@tresys.com>
On 01/14/2014 02:34 PM, Christopher J. PeBenito wrote:
> On 01/13/14 18:37, Russell Coker wrote:
>> On Mon, 13 Jan 2014 10:10:11 Daniel J Walsh wrote:
>>> Having separate labels on the unit file is not just for "user" domains. It
>>> is also for system domains, for example NetworkManager_t is allowed to
>>> start the following services.
>> OK.
>>
>> I've attached a patch I'm using which defines some unit types and adds fc
>> entries. Some of them are missing fc entries, presumably because the daemons
>> in question didn't have unit files at the time (this policy was taken from
>> Fedora some time ago).
>>
>> I've also added a stub systemd_unit_file() in init.if. The full systemd policy
>> patch will have to remove that. I think this is OK to get the uncontroversial
>> stuff included in the tree sooner.
> I don't have a problem with something like this. The big thing that concerns me about integrating systemd policy is it's structure. My big question is can we add it onto the init module and toggle rules (similar to init_upstart tunable) reasonably? Or does is it so different than sysvinit/upstart that it deserves to be implemented as a replacement module for init? If that's the case, that would surely have some interesting issues (e.g. what to do about initrc_t etc.) There's also questions about the socket activation and how that fits in.
How is it complicated? It shows us
policy-f20-base.patch
which we have in Fedora. And yes, initrc_t "goes away" how we know it
without systemd.
>
> I've been dragging my feet on integrating systemd stuff since I don't have such a good sense of the answers to these questions (and systemd functions were in flux for a long time.) A couple months ago I tried setting up systemd on one of my Gentoo systems, but that didn't go well, since its not well supported (a lot of Gentoo devs reject it's use). I haven't had a chance to retry on a Fedora system.
>
> That being said, I do want to get support in by the time RHEL7 final goes out.
>
next prev parent reply other threads:[~2014-01-27 14:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-12 7:06 [refpolicy] systemd policy Russell Coker
2014-01-12 12:18 ` Laurent Bigonville
2014-01-13 12:52 ` Russell Coker
2014-01-13 15:10 ` Daniel J Walsh
2014-01-13 19:02 ` Dominick Grift
2014-01-13 20:16 ` Daniel J Walsh
2014-01-13 20:22 ` Dominick Grift
2014-01-13 21:07 ` Dominick Grift
2014-01-14 14:49 ` Daniel J Walsh
2014-01-14 11:24 ` Dominick Grift
2014-01-13 23:37 ` Russell Coker
2014-01-14 9:46 ` Dominick Grift
2014-01-14 9:58 ` Dominick Grift
2014-01-14 12:35 ` Laurent Bigonville
2014-01-14 13:03 ` Dominick Grift
2014-01-27 6:56 ` Russell Coker
2014-02-06 14:40 ` Christopher J. PeBenito
2014-01-14 10:12 ` Dominick Grift
2014-01-14 12:22 ` Laurent Bigonville
2014-01-14 13:34 ` Christopher J. PeBenito
2014-01-14 13:54 ` Dominick Grift
2014-01-14 14:41 ` Laurent Bigonville
2014-01-14 14:55 ` Daniel J Walsh
2014-01-27 14:17 ` Miroslav Grepl [this message]
2014-02-06 16:32 ` Christopher J. PeBenito
-- strict thread matches above, loose matches on Subject: below --
2015-10-19 18:17 [refpolicy] Systemd policy Christopher J. PeBenito
2015-10-20 11:35 ` Dominick Grift
2015-10-23 19:23 ` Christopher J. PeBenito
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52E66A7C.4050001@redhat.com \
--to=mgrepl@redhat.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.