Re: Can we maybe reduce the set of packages we install by default a bit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 12 Apr 2019 11:21:13 +0200
Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:

> On Do, 11.04.19 17:08, Przemek Klosowski (przemek.klosowski@xxxxxxxx)
> wrote:
> 
> > > The logic in systemd is more strict on putting boundaries on
> > > resource usage, and thus will by default not allow you to consume
> > > resources while you are not logged in. It's really how this
> > > always should have been designed. However, we fully acknowledge
> > > that there are many uses where the ability to run stuff
> > > independently of any login as your own user is fine, but you need
> > > to turn on lingering for that (which is privileged), so that this
> > > is explicitly marked OK.  
> >
> > It IS very useful for systemctl to prevent resource leaks by
> > killing errant processes (hanging browser, etc)---however, as we
> > discussed, some processes should not be killed; I know which
> > processes I want to annoint this way, and I take responsibility for
> > their possible misbehavior.
> >
> > I understand that set-linger disables process harvesting for all
> > processes in the session, though, and I would like to just do it
> > only for SOME processes.  
> 
> If you enable lingering for a user, it's the "systemd --user" instance
> (i.e. the per-user service manager) that is started at boot and
> terminated at shutdown (instead of started at first login and
> terminated at last logout of the user), that's all.
> 
> If you then run code as user service (i.e. as a service started and
> managed by the "systemd --user" instance instead of PID 1) then it is
> lifecycled (and its processes killed as needed) by the user service
> manager. And you can configure the way you want killing to behave like
> you would for any systemd service: with KillMode= in the unit file.

This doesn't really fit with the security requirements we need.
Anything run outside of a user session needs to have an audit session id
and login uid assigned to anything run. We also need to have the
ability to know the name of the script that is being run in an audit
event.

-Steve
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux