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

81–90 of 91 posts

Re: X11 screen locking: a secure and modular approach

#81

Post by jcelerier »

rauhl wrote: post #28
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…

Oddly enough, I don’t have any of those issues anymore. Screen locking tends to just work these days. What doesn’t work well anymore is user switching: when I switch virtual consoles to either another user or the gdm screen the keyboard stops registering and the mouse gets slower and slower until it stops completely. Then some time later it starts responding again. The length of time it is unresponsive seems to be pr…

I use VT switching all the time, on a desktop with an nvidia card and a laptop with intel / nvidia, and I don't have any of your issues. I'm on arch linux so with recent kernels, systemd, etc... if that can help but I don't remember ever having them..

I don't use GDM however.

Re: X11 screen locking: a secure and modular approach

#82

Post by MisterTea »

rauhl wrote: post #32
MisterTea wrote: post #5

Earlier quoted context omitted.

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…

> Plan 9 front is my daily driver If emacs, SBCL & Firefox ran on Plan 9, I would see no reason to bother running Linux on hardware. But they don’t, and they probably never will. Maybe when I retire I’ll have time to work on porting them, but I have a long time until then!

Those are orthogonal problems to plan 9. tl;dr all this runs in vmx(3), though it is still in its infancy and slow as molasses but working good enough to scrape by.

Emacs is a poor fit as it already is an OS. plan 9, an operating system which encourages programs to talk to each other, offers no advantages to a monolithic text editing operating system. You're better off learning sam or acme and learn how they interact with the platform which is where their power comes from. That's how you use plan 9, you work with it, harness it. It's a kind of "be one with the os" zen thing.

SBCL I have no experience with but my guess is all the tooling and libraries are built around a 50 year old operating system. Porting languages isn't that big a deal, we have a buch like ocaml, python, Go, pforth, and maybe hugs/haskell among others. The issues are libraries which assume some unholy assortment of unix/posix/linux/whatever bindings and dependencies. plus we have no c++ because few at bell labs thought much of it even though they spawned it. Tells you something.

Firefox. The big one. The modern web browser is a primitive document viewer from the 90's which borrowed ideas put forth some 25+ years earlier by Ted Nelson and others in the 1960's and demonstrated by Doug Englebert in the MOAD. Now it can run computer code while displaying video, audio, text and images on your already existing computer. In plan 9 we would use separate tools to accomplish these tasks. A web browser would at most need to render html, ccs and handle basic javascript. The more complex stuff like pdf, audio and video should be plumbed to external programs which can be removed or swapped out as needed.

Re: X11 screen locking: a secure and modular approach

#83

Post by Lammy »

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…

* The screen locks, the machine suspends when the lid is closed, but then at some point the machine wakes itself up and overheats in your bag.

Re: X11 screen locking: a secure and modular approach

#85

Post by quotemstr »

JdeBP wrote: post #77
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

Ah, right. I remembered incorrectly. My larger question stands though.

Re: X11 screen locking: a secure and modular approach

#86

Post by spease »

cycloptic wrote: post #51
MisterTea wrote: post #27

Earlier quoted context omitted.

Both. glibc... No. And without boring you with anecdote I can sum it up by saying: Linux DE's feel like cheap Windows XP or OSX knockoffs. What's worse is every DE and their forks have their own duplicate DE companion programs such as explorer and notepad clones. I liken them to a Potemkin village; well polished but once you start looking behind things...

If your complaint is that you dislike clones of Windows and Mac, then the combination of tiling window manager, shell, tmux, and vim/emacs is usable and provides an experience that is completely different from those other operating systems. That didn't go away on Linux. There is also plan9port too.

No, the problem is that people keep reinventing the wheel over and over again, instead of picking one app and improving it so that their efforts are cumulative.

Re: X11 screen locking: a secure and modular approach

#87

Post by spease »

rvz wrote: post #25
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…

Seriously, If these distros still can't come together and get something as simple as screen locking right and consistent on X11, Wayland with a DE like GNOME or KDE, etc then it is difficult to recommend / market any Linux desktop distro to a typical consumer. It really is one of the smallest issues that would turn off a user moving to Linux, just to get work done. I wouldn't blame them if I see any of them ending up…

Yeah, I tried to get xsecurelock working with LXQt and systemd. What a mess. Eventually I had to just give up on it and switch back to xscreensaver-lock.

I posted a thread asking for advice and did get responses, but I haven't worked up the resolve to go back and try to get it working again. Last I checked, people were just suggesting I try something else, which kind of misses the point of the activity to uses the most secure lock screen that seemed to be available.

I appreciated the help, it just seems like the whole issue should be something provided by a systemd utility that you specify your lock screen for in a config file. I know people hate on it, but systemd really does tend to make it easier if you just kind of want your system fundamentals to stay in the background and just work rather than having to constantly meddle with them.

It's a point of pride to me that I've kept my Linux system going for so long (it's outlived one Windows and two Mac laptops) but it does feel like there's often a very myopic design to a lot of applications. That is, the author often expects you to be willing to context switch out of whatever you were doing for a few hours to learn their software to use it, and doesn't feel like there's any usability problem with the state of affairs. In the case of a lock screen, this was turning into multiple days.

I can only imagine that if things were simpler, it would make it easier to involve more people, bring them on board, and/or just to get stuff done.

Anyway - enough soapboxing.

https://github.com/google/xsecurelock

Re: X11 screen locking: a secure and modular approach

#88

Post by darkwater »

speedgoose wrote: post #63
darkwater wrote: post #52

Earlier quoted context omitted.

I don't want ads in my application menu, sorry. Good for you if you like them.

Yes this sucks. Do you remember the Amazon store integration in Ubuntu?

Easy to disable within Unity itself + you have a shitload of other DEs/WMs to choose from anyway.

Re: X11 screen locking: a secure and modular approach

#89

Post by catblast »

JdeBP wrote: post #74
catblast wrote: post #26

Earlier quoted context omitted.

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.

Most modern computers can software/CPU blit to a 4K screen at multiple frames per second. So this explanation doesn’t make much sense as is.

Re: X11 screen locking: a secure and modular approach

#90

Post by rauhl »

MisterTea wrote: post #82
rauhl wrote: post #32

Earlier quoted context omitted.

> Plan 9 front is my daily driver If emacs, SBCL & Firefox ran on Plan 9, I would see no reason to bother running Linux on hardware. But they don’t, and they probably never will. Maybe when I retire I’ll have time to work on porting them, but I have a long time until then!

Those are orthogonal problems to plan 9. tl;dr all this runs in vmx(3), though it is still in its infancy and slow as molasses but working good enough to scrape by. Emacs is a poor fit as it already is an OS. plan 9, an operating system which encourages programs to talk to each other, offers no advantages to a monolithic text editing operating system. You're better off learning sam or acme and learn how they interact…

> You're better off learning sam or acme

I beg to differ. Emacs is an excellent text-based operating environment, simply the best, without peer. I’ve used sam & acme, and they don’t compare.

> SBCL I have no experience with but my guess is all the tooling and libraries are built around a 50 year old operating system.

Some of the hairiest bits of Lisp (e.g. the pathname abstraction) are due to the fact that it doesn’t assume Unix.

Regardless, while I would prefer to boot directly into some sort of 21st-century Lisp OS which takes a lot of great ideas from Plan 9, that doesn’t exist; Plan 9 does. And if I ever get the spare time I intend to port Emacs & SBCL. And hope someone else will port Firefox.

Post reply on HN