From: dac.override@gmail.com (Dominick Grift) Date: Mon, 4 Dec 2017 10:24:11 +0100 Subject: [refpolicy] Policy for systemd inhibits In-Reply-To: References: <7caaf07b-7d91-ab48-6b89-5c26eb440cda@debian.org> <20171202111711.GA9947@julius.enp8s0.d30> Message-ID: <20171204092411.GA14459@julius.enp8s0.d30> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sun, Dec 03, 2017 at 04:38:06PM -0500, Chris PeBenito via refpolicy wrote: > On 12/02/2017 06:17 AM, Dominick Grift via refpolicy wrote: > > On Fri, Dec 01, 2017 at 05:03:47PM +0100, Laurent Bigonville via refpolicy wrote: > >> Hello, > >> > >> ATM it seems that the policy has no interface to allow applications > >> (NetworkManager, upower,) or users to manage systemd inhibits. (see denials > >> in attachment) > >> > >> I was thinking of creating an extra type for /run/systemd/inhibit/ and > >> allowing applications and users to interact with the files and pipes but > >> Dominick seems to prefer a different approach. > > > > Let me just make clear that i think a private type for /run/systemd/inhibit is not really needed because AFAIK logind maintains only two kinds of fifo files in runtime, and one of it /run/systemd/sessions already has a private type > > > > So that, to me, automatically implies that if a process can write an inherited login runtime fifo file, that it must be the inhibit one, since the other sesssions one has a private logind session runtime type > > > > logind inhibit clients need to do a couple of things AFAIK: > > > > 1. they write the inherited logind runtime fifo files > > 2. they use logind's fd's > > 3. they dbus system chat with logind > > 4. they are dbus system clients > > > > The only way AFAIK this differs from logind session clients (apart from the different fifo file) is that logind needs be able to read logind session clients state in addition. > > Perhaps I misunderstand, but it seems like these two approaches are the > same. Essentially, but Laurent's suggestion to create a private type for the inhibit pipes *seems* not needed to me. It does not do much harm either i suppose. > > > >> > >> I'm not sure what would be the preferred way here, what do you think? > >> > >> Regards, > >> > >> Laurent Bigonville > > -- > Chris PeBenito > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20171204/9b687e3c/attachment.bin