Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

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 ..in 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 Blame Washington (Score 1) 198

Technology has been a boat anchor dragging down the industry thanks to regulations like Hippa, and requirements that all records be kept electronically. Paper charts are banned. now. This is a classic example of what happens when legislators regulate something they know nothing about. I see it everyday, as I work at the helpdesk of a major midwestern hospital chain. I am convinced all the technology that end users can't figure out has led to dead and injured patients. I am a perma-temp, where I work, not an employee. Outsourcing in healthcare is another problem, but not the one we are talking about here. Anyway, many people working in healthcare are technically illiterate, and refuse to learn. Also software like Epic is too complicated for anyone but engineers. My mother, who was a nurse, is now happily retired. Epic and other high tech whizbangs made her last years in the industry hell. The worst part of it all is cost. Computers, commercial software, and all the support staff needed cost so much more than paper charts did. All they really needed to do was to make PDF of the old paper charts, and let people type into them That would have fixed the problem of scribbly doctor's handwriting. Washington broke it. Will they ever fix it?

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.

Slashdot Top Deals

I program, therefore I am.

Working...