From: pebenito@ieee.org (Chris PeBenito) Date: Sun, 3 Dec 2017 16:38:06 -0500 Subject: [refpolicy] Policy for systemd inhibits In-Reply-To: <20171202111711.GA9947@julius.enp8s0.d30> References: <7caaf07b-7d91-ab48-6b89-5c26eb440cda@debian.org> <20171202111711.GA9947@julius.enp8s0.d30> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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. >> >> I'm not sure what would be the preferred way here, what do you think? >> >> Regards, >> >> Laurent Bigonville -- Chris PeBenito