On 2 June 2016 at 15:17, Justin Brown <justin.br...@fandingo.org> wrote: > On Thu, Jun 2, 2016 at 1:26 PM, Ivan Chavero <ichav...@redhat.com> wrote: >> Well, if i'm writing a malware i'll make sure it uses systemd-run so it > keeps on running. > > The point of the feature is not to prevent users from running anything in > the background. It's that *anything* the user runs has proper systemd > confinement, so it's obvious and manageable by the administrator. Without > this feature, the only reliable way to achieve the same thing is to reboot > every system. > >> This default is nonsense the only thing that it really does is break stuff >> that relies on processes being executed after the user closes his session. >> Yes, there's an obscure systemd-run command that only the systemd devs know >> and can make your programs run forever but what's wrong with "&" or just >> running "screen" to create a persistent session?? > > Maybe it's obscure to you, but it's foolish to suggest that it will forever > be so. What's wrong with your shell understanding that "&" needs more > sophisticated handling than fork/exec* these days? There's no reason why > shells can't handle this for you, or you can setup your shell to handle it > for you. There's already been discussion about creating wrapper scripts in > Fedora for screen and tmux that automatically handle execution via > system-run, so I'm unsure what the issue is. >
Mostly because that is a naive view of the amount of work that will need to be done. It has to be more than a wrapper script, it will take a bunch of patches to many applications for it to work. Those projects need to be aware of this change or some patch needs to be held in every OS when the upstream says 'screw this' This isn't a sentence that these things can't happen. Supposedly various ports to MacOS-X (and possibly other OS's) have carried various patches to work with init systems that do something similar. So it is possible. However the want to do any of that was short cut from the beginning because of the standard cycle of systemd squabbling. 1. There is a problem for a certain group that systemd people care about (usually desktop but not always). 2. Systemd puts in a fix for that problem. 3. Someone who isn't using the system that way gets affected and asks/complains/bitches about the fix (depending on the person). 4. Communication goes down hill with the following items you can checkmark regularly: A. Someone 'representing' systemd says its right and it is dragging the neanderthals into the light of 21st century computing. B. Someone 'representing' grognards says its right and it doesn't want know-it-all eggheads pissing on it all the time. C. Someone 'explains' how this fixes a security problem. D. Someone 'explains' how it causes a security problem. E. Both sides tear apart each others arguments. F. Both sides yells, screams, throws insults, emails 'anonymous' death threats to people in the other side. G. Both sides say they are going to take their toys and go home. H. Eventually FESCO has to play adult and tell the groups to work together or no one gets to play. I am guessing we are hitting E and will be going to F soon. G will come sometime after F24 is released (usually 2-3 weeks after release). H. will happen after the deadline for features in F25 occurs. [PS I do not condone or think that any of the steps are good or should be done. It just seems to be the standard bingo for this software. Someone might also be able to put dnf or GNOME into similar categories. ] -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
