Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Systemd-free (Score 1) 179

bogus argument - this so-called security risk is also there when the user is logged in - you cannot really make security contingent on a user being logged in, because logged in means zip - user can be logged in a system for weeks w/o doing anything reality LP redefines what it means to have a user account, and what it means to be logged in, arbitrarily limiting the user (and this *is* windows think), I mean next thing he figures out its a good idea for security to log user out at midnight, eventually figuring out he needs positive id checking user's ass is continuesly behind the terminal..)

No, it is a real security problem; lingering processes have been used countless time to regain access to systems from the outside. Pre-systemd there wasn't even a good and reliable way to kill a (logouted) user's processes across servers (pkill was never a standard and it is unreliable since both broken and malicious programs can escape it).

Hyperbolic assertions about what LP might do are lame arguments. Besides timed logouts have been the order of the day for decades; I have never worked on a sensitive system that allowed the user to stay connected for weeks on end; it just too dangerous to allow that.
And don't forget that LP and the rest of the systemd developers really knows "user and session management" in Linux; they have practically invented and maintained all the core Linux software used for this like CK and logind.

Instead of abusing Unix signals like "nohup", lingering programs should just use PAM or similar to gain permission to run in their own scope; much better and much more granular security.

Comment Re:Systemd-free (Score 0, Redundant) 179

Lennart is too young to have read "The Cathedral and Bazaar" when it came out. He comes from an MS Windows background so never knew the Bazaar idea existed and has no patience with people who try to suggest it does.

Lennart Poettering have been working strictly on open source Linux software ever since he graduated. He has at least +15 years developer experience on Linux. I have no idea why you think he has a MS Windows background. Did you just made it up?

That's why things like persistent user processes in the background (about chapter three in most scripting books) is just not something he sees as being something that should exist.

He says that:
1: it should be an easy admin task to enable-disable users ability to run such tasks since they are a security risk (eg. a lingering ssh connection out through the firewall can be reversed so it can be used to connect back into the system).
2. As default, only programs that explicitly have permissions (from PAM etc) to linger after logout should be allowed to do so.

So he has no problems with lingering processes, he just thinks they should be secure and easy to admin. No sane modern OS would ever implement the current Linux scheme with unrestricted ability for users to run arbitrary programs after logout (and even after the account have been locked).

Comment Re:WTF (Score 1) 924

Telnet and ssh are different programs, you incomprehensibly stupid piece of shit. I know you're a troll, because only a troll could be so stupid.

Yeah, I actually know the difference between those two programs, and old enough to have used both telnet and see ssh replace it as the default way for connecting to other machines.

People unable to cope with technological changes like the transition from telnet (rsh/rlogin/etc) to ssh, SysVinit to systemd, or the future, Xorg to Wayland, just eject themselves out of tech.

Comment Re:From a security perspective... (Score 1) 924

Well, you assume every change is for the better.

No I don't. I just accept technically superior solutions as the way forward, even if they means another way of working.

I have no sentimental feelings for old, close source, Unix systems made by money grabbing, Linux-hating companies. So I have no problems discarding ancient Unix ways of doing things if I find new ways that are better.

Finally, I actually study the new tech I embrace by reading the technical documentation. That is apparently a lost art among many modern Linux users.

Comment Re:From a security perspective... (Score 1) 924

that will create a new scope and anything executed from that scope will remain in it

Something handed over to a thing like torque/openpbs or other scheduling systems will obviously not remain in the scope - as would many other things.
Closed source workstation software frequently has many parts and it is impractical to write little wrapper scripts around each portion that is called in a non-trivial way.

It goes without saying, that if the close source vendors want to sell their stuff as supported on RHEL and E-Suse, and this is something they certainly will, they will make sure their stuff works with systemd.

Not familiar with "torque", but this doesn't seem like anything a single user will start from a terminal. It seems more like a fundamental system service, and therefore won't have any problems with "KillUserProcesses=yes".
Nor would any jobs it handed over to other machines be affected, unless it happens to "physically" login with username and password and run the instance under that user account. Highly unlikely IMHO.

Comment Re:From a security perspective... (Score 1) 924

Just lock the session instead of logging out

The pathetic little troll appears to have no idea that running applications remotely via X instead of MS Windows RDP is a thing.

X's network transparency have basically been broken for many years for anything complex. For simple uses of old legacy software it may still work for some. But really, I and many others are cheering for the day we can clean our systems for that insecure monster called X and start to use Wayland. Yeah, that will break peoples workflow too. But that is how progress works.

Peter H.S. - why are you wasting all the time of all these people with your nonsense and deliberate antagonism?

If you don't want me to answer your often rather unsavory personal attacks, then just stop talking to me. I don't remember starting to address you in the first place.

Comment Re: misleading title as usual (Score 1) 924

Hey, dickhead: many of us run many many machines, and not all of them have systemd.

Then use different procedures for different machines. Not a problem in the real world where people often work with several incompatible OS's. Anyway, that problem will solve itself as the non-systemd Linux machines slowly are phased out.

Comment Re:I assumed this was already a default (Score 1) 924

Even with the new settings, no user process will be killed on exit/logout if the user have told the systemd not to.

FTFY, jackass. systemd ain't my momma and never will be.

Maybe you need a real mother that can love you unconditionally for what you are. You certainly seem like a bitter bileful person in desperate need for love.

Comment Re:WTF (Score 1, Funny) 924

Or even better. Start screen automatically at boot by running it as a .service

You see guys - they just don't get multi-user and cannot even dream that a second user may want to use something like screen as well.

That stupid single user MSDOS mentality was obsolete before MSDOS even started and should be kept out of modern systems.

Please be aware that we are talking about user .services, not system .services.
A users services are totally independent from other users services, and the system services.
Each user can control their own services with standard systemd tools like "systemctl start screen.service" and you can employ the whole suite of systemd features like socket activation, AmbientCapabilities, Cgroup resource management, etc. on such services.

I think the systemd developer group is the single most knowledgeably Linux developer group when it comes to multi-user Linux. The very existence of "systemd-logind" is a proof on how much better multi-user Linux work on systemd compared to any non-systemd distro. I mean, running Xorg rootless is only safe on systemd distros.

Comment Re:From a security perspective... (Score 1) 924

So please name me just one example of breakage or non-contrived stuff that are no longer possible to do with the new systemd settings?

Closed source workstation software. The user can't modify the process launch and put "systemd-run" in front of things and when they close the GUI launcher they still expect their stuff to run for hours or days instead of being killed off by a pointless major policy change.

Just lock the session instead of logging out. That would be the typical thing to do with a workstation since it runs a DE of some sort.

I must say I have a hard time imagine CLI software being launched from a GUI and then detach from the terminal. But I don't think there is any problem with using "systemd-run" on the GUI; that will create a new scope and anything executed from that scope will remain in it. So even if the GUI is closed, the scope will remain with all the processes launched from it.
At worst they can just add the user to the "KillExcludeUsers=" in logind.conf to have the old behavior.

Comment Re:WTF (Score 1, Interesting) 924

So systemd is changing the behavior of every other program? I still have telnet, and still use it. But not for the same things I used to. But it still works the same way. Installing openssh did NOT change the behavior of telnet. ssh did not kick telnet off my system. I can kick it off if I want to - I sure as hell don't want the ssh (or the openssh installer or whatever) kick off telnet for me.

Oh yes, telnet was kicked off the default installation list along a lot of other inherently insecure Unix stuff like rsh and rlogin etc. Instead you got ssh. People whined about that too; suddenly they had to manually install a telnet client (lets just suppress the memories that some Linux distros came with a telnet-server as default).

ssh dramatically changed the whole workflow on both Linux and Unix, and a lot of people didn't like that. Same with packages and package management (how I don't miss hand patching and compiling). These days it is systemd that changes how Linux work, and I must say I much prefer how it does things as opposed to the old days of SysVinit.

The bottom line is that tech changes all the time, or else it becomes obsolete. That is just the price of progress. Cling to the old ways, and you and your skills become obsolete in the same way.

Comment Re:WTF (Score 1) 924

But the new defaults really _is_ best practice. Denying that is like denying that ssh is better than telnet.

Asserting that over and over doesn't make it true. Your argument seems to be that "With this change, people can at least ensure that their user run service doesn't DoS the server unintentionally." Which this change doesn't even do.

Yes it does, because using systemd-run enables you to use resource management on the user run service. See for some options.

Also, it really is best practice to totally clean the user session at logout, only allowing explicitly permitted processes to continue to run.

Comment Re:From a security perspective... (Score 1) 924

It does create (which seems to be the whole idea of systemd) incompatibilities with other systems. Suddenly, I now have to care if my script is running on Systemd/Linux or if it is running on any other Unix system (and yes, I have scripts that currently work perfectly without modification on IRIX, Solaris, and Linux).

Cross platform scripts have always been problematic. Sometimes they work, sometimes they get broken when things change. Solaris changed a lot with SMF etc, and Linux with systemd. That is just progress.

Most of the old close source Unix's have chosen not to evolve and are now firmly niche OS's working in a very narrow confinement (and loosing ground there too every year).
Linux runs everywhere, from tiny embedded to clusters and supercomputers, and therefore have other needs than classic Unix. It is just logical that Linux evolve with new features while many Unix's are standing still, and that therefore it will become harder and harder to run platform-independent scripts on them. While it may be inconvenient to some, it is what is saving Linux from ending up in the same, small dying niche as the close source Unix's.

In 10 years there will be even less Irix, AIX, Solaris etc., but Linux has a fighting chance still to be relevant in the future, exactly because it changes.

Comment Re:From a security perspective... (Score -1, Troll) 924

Just edit your scripts.

Are you serious? How about you edit my scripts? You broke it, you fix it.

Yes I am seriously suggesting to edit scripts so they work with new tech.

But I don't care whether you edit your scripts or not. If you prefer prefer broken scripts to editing them, that is your problem, not mine.

Slashdot Top Deals

Intel CPUs are not defective, they just act that way. -- Henry Spencer