On Fri, 21.08.15 13:29, Christian Seiler ([email protected]) wrote: > On 21.08.2015 12:04, Jóhann B. Guðmundsson wrote: > > Should not the solution for this be tied to the user and group field > > mentioned in the unit so for example the postgresql type service unit > > contains... > > User=postgres > > Group=postgres > > > > Which would mean that the posgres user could start,stop,restart,reload > > the postgresql.service as well as any user that has been added to the > > postgres group? > > For postgres it would probably solve this problem (as long as it's > configurable), the question is whether you'd maybe rather want something > a bit more generic for the future. > > I would suggest a setting like > > UnitControl=alice bob group:foobar > > that would enable alice, bob and everybody in group foobar to control > that specific unit. (The name for the setting is debatable.) > > That would be quite simple but still very flexible and generic. The only > problem I see is that for this to be useful, you'd need to be able to > resolve the names, and you don't want to do that in pid 1. Question is > whether PolicyKit (not pid 1) can do that check for systemd with systemd > just passing along the whitelist somehow. (Don't know too much about > PolicyKit yet to answer that question myself, unfortunately.) The same > problem also applies to the solution of tying it to User=/Group=, however.
systemd is not the place to implement ACL policy in. PolicyKit is that place. Hence: we should just pass the unit name to PK, and that's it. If you want to allow specific users access to an action on a unit, then encode that in PK rules. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
