SoylentNews is people
SoylentNews
In case you penguin botherers were feeling left out, the folks over at iTWire bring us this little fun bit o' news:
Eset says it has found a Linux variant of the KillDisk malware used in the late 2015 attack on the Ukraine electricity system.
Like its Windows counterpart, the Linux version of KillDisk encrypts files, rendering the affected system unbootable. It asks for the same 222 Bitcoin (around US$278,000) ransom, but the encryption key used is neither stored locally or sent to a remote server, so even if the perpetrators are paid they have no way of reversing the process.
Eset says its researchers have found a weakness in the encryption method that makes decryption "possible, albeit difficult." Exactly how decryption can be performed was not disclosed.
It's nice to feel noticed but I could personally do without this particular kind of attention.
(Score: 2) by Scruffy Beard 2 on Wednesday January 11 2017, @09:23PM
I have been experimenting with using multiple users for different tasks.
It does not appear to be well-tested. Windows XP's "switch user" functionally looks like it was actually hard to duplicate with GNU/Linux and Xorg.
It is almost easier to use 'su ' in the text console.
(Score: 2) by Dr Spin on Wednesday January 11 2017, @10:28PM
I cannot comment on the capabilities of WinXP, but you can login as multiple users in Linux and switch with CTRL-fx,, where X=7 for the first login, and higher numbers for later logins.
Currently it seems to go a bit wierd in Ubuntu-Mate, but it used to work quite well in the past. (And so did CTRL-f1 to f6 for consoles, but that is also a bit stuffed, and locks up).
Probably the combination of Ubuntu and systemd was a bad move, but there could be other explanations for regression failures as well.
If you want software that actually works, perhaps the BSDs are a better choice.
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by Scruffy Beard 2 on Thursday January 12 2017, @12:21AM
I am supposed to be configuring FreeBSD instead of posting on the Internet :P
By default, Xorg only uses one VT. Getty uses 6 by default (as you mention)
But yes, systemd tries to do thing like change permissions for the sound card on the fly when you change users.
(Score: 0) by Anonymous Coward on Thursday January 12 2017, @11:05AM
Nope.
Getty uses one: The one specified where it gets started.
X.org uses one: The one specified where it gets started.
If you want either to use more than one, you need to start several copies.
(Score: 3, Informative) by Marand on Friday January 13 2017, @12:45PM
For the record, the AC's right: getty only uses the one it's started on, same as X. You're confusing distros choosing to start six copies of getty (as seen in /etc/inittab) on six ttys with some perceived innate property of getty that doesn't exist. If you want to, you can lower the number of spawned getty instances (useful on massively resource-limited systems), add more spawned instances of X on 8/9, or combine the two and only spawn one getty and make 2-9 be X servers. (No idea why you'd want to, though, unless you're setting up some kind of weird multi-user system where you'll have 5 people using the same system simultaneously.)
"User switching" features in DEs are doing the same thing, more or less, just dynamically. When you choose to do a user-switch, a new X server is fired up on another tty (usually 8 and up, since distros typically start the first X on 7), the current one activates whatever screen locking it does, and it switches over to the new tty. You can swap between them using the same alt-F[x] (or ctrl-alt-F[x] from inside X) hotkeys you use to swap ttys.
Switching X servers like that is overkill outside of actual multi-user systems, though; for basic separation of concerns-style account use, there are other ways that I covered in my other comment.
As for problems with term switching Dr Spin mentioned, that's most likely GPU related. For example, using an nvidia GPU with the (much faster, and generally good) proprietary driver has long been a source of frustration with regard to terminal switching, especially once it became popular to do hacky shit to make the text consoles fancier. Nvidia's drivers have never gotten along well with that, and the workaround has generally been to force the kernel to give you boring old 80x25 (or whatever) text ttys if you have problems switching. Though YMMV there; it's gotten better the past few years, and I'm currently using an nvidia GPU with the proprietary driver without tty-switching problems.
(Score: 3, Informative) by Marand on Thursday January 12 2017, @12:46AM
If you just want a full user-switch feature, that depends largely on the desktop manager (kdm, lddm, gdm, etc.) and the desktop environment. However, your comparison to su make it sound like you want something a bit more fine-grained... If that's the case, it's likely what you'd rather have is attainable either by using XPRA [xpra.org] or something like kdesu [man.cx] or gksu [man.cx].
The former, xpra, is basically like a GUI equivalent of using screen or tmux, which means that if you want, you can have multiple X servers running as different users and run different applications in different user contexts, but with all the windows usable simultaneously. The different users have their own homedirs and thus can't access each other's files, which lets you separate things as much or as little as you paranoia desires.
The latter options are just GUI wrappers around su and sudo, and work similarly to them, except that they also transfer GUI environment information like Xauth, and are thus good for running graphical applications as different users. They tend to be used for privilege elevation, same as su, but they accept the -u [username] flag, so you can do something like gksu -u scruffybeard3 chromium to run a copy of Chromium under its own user. If you've got your homedir permissions set up properly, that scruffybeard3 process won't have a way to read anything in ~scruffybeard2.
(There used to be a toolkit-agnostic option to gksu and kdesu called 'sux' but it vanished years ago, sadly.)
Either way you do it, you'll have different configuration files for each user as well, so you can also tailor the accounts to different degrees of paranoia. For example, you could have a generally locked-down "everyday browsing" user and a trusted browsing one with different security settings, more/less strict NoScript rules, etc. You can also make the different accounts stand apart visually by setting different GUI colour themes. The unsafe account could have a red tint to the GUI elements, for example.
Doing something like this is probably good enough for most things, but if you want to take it to the logical extreme, there's always Qubes [qubes-os.org], which does basically the same thing but with entire VMs dedicated to each task group you create.