Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

X11 screen locking: a secure and modular approach

leahneukirchen.org

Post reply on HN
Print view View original

71–80 of 91 posts

Re: X11 screen locking: a secure and modular approach

#71

Post by AnIdiotOnTheNet »

cycloptic wrote: post #60
AnIdiotOnTheNet wrote: post #58

Earlier quoted context omitted.

> It's open source after all, the control is in the hands of the user. That's true of proprietary software to roughly the same extent: if I don't like how things are I am free to make my own or just not use it.

I don't follow. In my experience setting up a build environment and changing a couple lines of code provides a lot more control (and is a lot easier) than rewriting the whole thing from scratch or ditching it entirely for something else. If your distro's package manager supports source builds then you probably don't even need to use tools like GNOME Builder to make quick modifications.

If you find setting up a build environment to change a few lines of code more reasonable than switching to software that wasn't so boneheaded as to hardcode the value in the first place, then good for you I guess. I personally don't have much patience for it.

Re: X11 screen locking: a secure and modular approach

#72

Post by globuous »

kstenerud wrote: post #2

My experiences with screen locking on Linux over time, using various machines: * The screen doesn't lock, and remains on while the lid is closed. * The screen doesn't lock, but does turn off when the lid is closed. * The screen locks, but the machine doesn't suspend when the lid is closed. * The screen doesn't turn on after the lid is opened. Key commands work, though. * The screen turns on after the lid is opened, b…

I'm lucky not to experience such problems on my arch with my current machine, but I've run into these issues on my past machines. However, my graphic designer friend working on Windows (he needs Adobe cs and blender and therefore needs a good gpu in an affordable machine ruling out Macs) keeps on having this problem. Drives him nuts because he'll close the lid, pack the laptop in his backpack to go somewhere only to realise when taking it out that the laptop is close to being to hot to touch. On a 3k msi that's a few months old, it scares him to death ever time it happens, which is quite often. So I guess this is a harder problem than it seems !! I don't remember ever having this problem on my Mac.

Re: X11 screen locking: a secure and modular approach

#74

Post by JdeBP »

catblast wrote: post #26
BiteCode_dev wrote: post #16

Earlier quoted context omitted.

+1. I'll add: * The screen locks, unlock, but the network card cannot wake up anymore and requires a reboot. * The screen locks, let you enter things, but doesn't seem to react, then suddenly, replay all the things for 20 seconds in 1 seconds, and displays an error message * the screen locks, but you can see the unlock screen for a few seconds when you wake the laptop up

The first 2 sound more related to suspend rather than screen locking.

I've had the second, and it wasn't related to suspend. For some reason, the GUI decides to do a software bit-blit of the entire screen, which takes tens of seconds, before it lets xscreensaver put up its dialogue box. So don't assume that this is always suspend-related. There are several quite varied possibilities.

Re: X11 screen locking: a secure and modular approach

#75

Post by JdeBP »

brokensegue wrote: post #66
tryauuum wrote: post #33

Earlier quoted context omitted.

I can't stop hating Microsoft for WSL. Yes, it is a way forward for the company but I still have a feeling they have found a perfect way to make younger generation ignore Linux completely.

Ignore Linux by using Linux?

In the first Windows Subsystem for Linux, Linux was the thing that was actually missing, with Windows NT taking its place.

Re: X11 screen locking: a secure and modular approach

#76

Post by agumonkey »

BiteCode_dev wrote: post #43
AnIdiotOnTheNet wrote: post #22

Earlier quoted context omitted.

> It's good enough I've been hearing that for between 15 and 20 years now. I believe this mentality is part of the reason it never seems to get any better.

Oh it did become better. I've been using linux for 15 years. It's better in every way. My mother has been using Ubuntu for 7 years now. It would have been impossible in the early 2000. It is better. It is productive. It is even a good experience. I'm no a masochist, I buy and use proprietary software. I use Linux because I want to. I'm not just not blind to it's many shortcommins. Last week I used Windows with a clie…

That's true, web standard made OS less critical for an average user, and time let some other native apps improve and polish (things like krita and blender comes to mind)

Re: X11 screen locking: a secure and modular approach

#77

Post by JdeBP »

quotemstr wrote: post #68

I don't understand why we don't just lock screens by switching to a different virtual terminal running a different X server. If the lock screen doesn't share an X server with the user session, a lot less information can leak. This entirely-separate-session approach is what Windows uses, and it works great there.

It's a separate desktop, but not a separate window-station, let alone a separate session. The clipboard and atom table are not separate, because they belong to the window station; and a session is something rather different on Windows NT.

* http://jdebp.uk./FGA/windows-nt-session.html

Re: X11 screen locking: a secure and modular approach

#78

Post by secure »

eximius wrote: post #67
ubercow13 wrote: post #15

I prefer https://github.com/muennich/physlock It seems more secure as it bypasses X, and you can be sure (can you? I just assume this, I don't really know) your input is not even being passed to X when your screen is locked. In practice I've found it very reliable.

never been able to get it to work. I've been using i3lock on my machines, not sure how well it does on suspend, though.

I recommend to combine i3lock with xss-lock to get automatic screen locking on suspend:

xss-lock --transfer-sleep-lock -- i3lock --nofork

Re: X11 screen locking: a secure and modular approach

#79

Post by cycloptic »

AnIdiotOnTheNet wrote: post #71
cycloptic wrote: post #60

Earlier quoted context omitted.

I don't follow. In my experience setting up a build environment and changing a couple lines of code provides a lot more control (and is a lot easier) than rewriting the whole thing from scratch or ditching it entirely for something else. If your distro's package manager supports source builds then you probably don't even need to use tools like GNOME Builder to make quick modifications.

If you find setting up a build environment to change a few lines of code more reasonable than switching to software that wasn't so boneheaded as to hardcode the value in the first place, then good for you I guess. I personally don't have much patience for it.

There is no need to set up a build environment. GNOME Builder does it for you, for GNOME packages. For other packages, on my distro (Debian) the package manager does it for you. It's 4-5 commands to download dependencies, download source, rebuild and reinstall ANY package. Comparatively, the cost of switching can vary wildly depending on the software and available alternatives.

Re: X11 screen locking: a secure and modular approach

#80

Post by thaumasiotes »

MisterTea wrote: post #5
kstenerud wrote: post #2

My experiences with screen locking on Linux over time, using various machines: * The screen doesn't lock, and remains on while the lid is closed. * The screen doesn't lock, but does turn off when the lid is closed. * The screen locks, but the machine doesn't suspend when the lid is closed. * The screen doesn't turn on after the lid is opened. Key commands work, though. * The screen turns on after the lid is opened, b…

Most of what you describe isn't the screen lock but sounds more like something isn't communicating system events properly. That or bad hardware with poor open source driver vendor support. Also, this is why I don't use Linux any more. It's grown into a dumpster fire of ad-hoc patches from big corps looking to hammer every last drop of cloud server performance or poorly designed desktops made by people who obviously d…

> Windows 7 still powers my gaming rig by it most likely will move to Linux because Steam.

There are some kinks to be worked out. I'm seeing the following scenario:

I have Ori and the Blind Forest installed through Steam on Ubuntu 18.04. Attempting to play it through the steam client causes a crash. Navigating to the install directory in a terminal and running the simple command `wine oriDE.exe` runs the game with zero apparent problems.

Of course Steam isn't using the local wine installation, but... still? The game works flawlessly with the absolute bare minimum of effort. What's Steam doing instead?

(I tried watching the startup process in the Steam console, but it appears to be committed to printing only uninformative messages.)

Post reply on HN