With EL10, tigervnc and xorg are no longer part of the distribution.
Our existing users are trained on tigervnc style workflows.
A shift to the weston desktop gives us the closest compatibility.
However, it uses pam for authentication.
We can either keep the existing tigervnc passwords or break compatibility.
If we keep the existing password, we will need a tool that can read the ~/.vnc/passwd file to use with pam.
Similarly, a tool to write the password in ~/.vnc/passwd is necessary on EL10.
Or we could break compat with EL9 and make a ~/.config/weston/vncpasswd.
The source code for this tool should be kept under : https://github.com/fermitools
On systems with tigervnc the vncpasswd command writes out ~/.vnc/passwd and prompts for an additional "read-only" password.
The tigervnc server itself performs the authentication to validate the password matches and assign priviledge level.
There are lower and upper limits on what can be used by tigervnc for passwords. These limits are not relevant for weston's use of pam.
The tigervnc server will often refuse to use password files with group or other read (ie. not-600).
On EL10, we don't have an option to delegate "read-only" access.
- How do we let shared accounts, which have no local password, use VNC sessions?
- Should users without a
~/.vnc/passwdfall back to regularpamauth? - How do we make something that works well enough that existing
~/.vnc/passwdfiles will work withwestonandpam? - Do we care if files generated by the "new tooling" work on EL9 hosts?
- Any local "check auth" needs to run via
pam_execor via our ownpammodule, how do we keep this safe? - Should the path to
~/.vnc/passwdbe something configurable (is currently intigervnc)?
- Must be easy to build on major Linux distributions - Fedora, RHEL, Debian, etc
- Must be written with a security first mindset
- Must be compatible with selinux in enforcing mode
- Must engage seccomp where possible
- Must include detailed manpages
- Must protect against time-of-check-to-time-of-use attacks (file swaps, etc)
- Must protect against symlink redirection
- Clear way to configure the actual location of the vnc password file.
- there should be a compiled in default path
- from a file in
/usr/somethingorother, a file in/etc, a file in~/.config/somethingorother, and a commandline switch.
- Source code must include self tests
- Source code must include automatic linting
- Source code must include automatic formatting
- Source code must include static analysis
- Source code must include packaging for RPM distributions
- Must be compatible with
tigervnc's file format?- Must preserve existing read-only password if found
- Write passwords to
~/.vnc/passwd(or configured location) - Must support non-interactive creation of password file
- Must ensure correct permissions on
~/.vnc/passwd(or configured location)
- Good actual name for this tooling
- Must be compatible with
pam_execor be its ownpammodule - Must validate against "read-write" password contained within
~/.vnc/passwd(or configured location) - Must have lightweight memory footprint (sub
16M) - Must have low latency responses (sub
50ms)
- Cannot use
landlockdue to home areas for some users under a non-/homepath - This is Linux only software
- Must not assume user home area is under
/home - It does not need to run on RHEL9 or earlier
- Should not prompt for a "read-only" password
- Must not use any elevated priviledges
- Must not log anything considered sensitive
- Must not use any elevated priviledges
- Must not log anything considered sensitive
$ vncpasswd
Password: ******
Verify: ******
Password updated successfully.Other workflows?