Closed jallbrit closed 5 years ago
@stapelberg
I just merged https://github.com/i3/i3lock/pull/226, so let’s give people a few days to test it out and report any issues they might face.
I’ll aim for doing a new release this weekend.
Only noticed this while going through the changelog: @LorianColtof’s https://github.com/i3/i3lock/pull/183 changed the Makefile so that i3lock is now installed setuid root. Can we change this to only grant the required capability (using setcap
)?
I’d prefer it if i3lock did not run as root, or at least not by default.
I looked through how the TTY locking works; we could probably use setcap to add the cap_sys_tty_config capability, but the issue is that we open /dev/console as read/write, and /dev/console is 0700 and owned by root:root. AFAIK, the extended attributes system isn't flexible enough to add read/write permission to one particular file.
It's possible to make a separate locking binary which is simple enough to be much less likely to have security bugs, and make that a suid binary. I made one here: https://github.com/mortie/i3lock/blob/feature/separate-locking-binary/i3lock-tty-switching.c
However, we're fundamentally giving unprivileged users permission to globally lock and unlock TTY switching. This feels very wrong. I wouldn't want some admin to install i3lock on a shared system and suddenly without knowing it allow any of their users to disable TTY switching. At the same time, TTY switching is obviously a potential security issue.
It seems like neither xscreensaver nor google's xsecurelock feature TTY switch locking. physlock is the only screen locker I've seen thus far which disables it, and that's also just a suid binary which uses VT_{UN,}LOCKSWITCH
ioctls.
What do you think @stapelberg?
I looked through how the TTY locking works; we could probably use setcap to add the cap_sys_tty_config capability, but the issue is that we open /dev/console as read/write, and /dev/console is 0700 and owned by root:root. AFAIK, the extended attributes system isn't flexible enough to add read/write permission to one particular file.
It’s possible to do this using setfacl(1)
, but we can’t rely on that across distributions.
It seems like neither xscreensaver nor google's xsecurelock feature TTY switch locking. physlock is the only screen locker I've seen thus far which disables it, and that's also just a suid binary which uses
VT_{UN,}LOCKSWITCH
ioctls.What do you think @stapelberg?
Yeah, I think we should revert our merging of that feature. People should use vlock(1)
instead if they care about virtual console locking. Many users will never use virtual consoles. I will do the revert soon, unless someone convinces me not to.
i3lock 2.12 was released! \o/
I'm submitting a…
Current Behavior
The
--lock-console
option is not available on the most recent release. It has been a considerable amount of time since the last release and I was wondering when the next one is planned.Expected Behavior
Latest release was expected to contain the
--lock-console
option.Reproduction Instructions
i3lock --lock-console
Environment
Output of
i3lock --version
: