Support sudoedit

[Aleksanaa]

sudoedit allows you to edit a file with a normal user and save as root, which means users can use their own editors with complex configurations without worrying about running too many processes (such a lsp) as root. It basically copies the file (possibly with privileges) to a temporary path, allows the user to edit it, and moves it back.

[LordGrimmauld]

I am not opposed to doing this, but there will be limitations.

• AUTH_ADMIN_KEEP can't work with a run0-based sudoedit shim. The reason for this is in how AUTH_ADMIN_KEEP works in polkit: It requires pty, login session, parent pid and cgroup to be the same. These requirements are somewhat loosely documented in auth_keep: do not ask for reauth if new process shares same UID/parent/cgroup/tty polkit-org/polkit#533. This becomes challenging here. The shim for sudo works by replacing the shim process with the run0 process via exec, inheriting the parent pid from the shim, meaning authentication is kept. On a sudoedit shim, this does not work: The run0 (or systemd-run) process would need to be forked from the shim process, so the shim process can linger and watch the file being edited. That means each sudoedit would be its own authentication session, and AUTH_ADMIN_KEEP only ensures you don't have to repeat your password each time you save.
• A trivial implementation would do the following:
  • start the shim
  • copy the file (checking permissions and potentially asking for auth to copy). Copy needs to be kept in a secure location where only the user performing the edit has access. I am not sure how to best achieve this, suggestions welcome. I guess i could check what sudoedit does here. 600 in /tmp/<something> is the trivial choice, but it does allow any program to edit it while it is open in editor - ideally the file should be owned by the editor, with no-one else except root (via run) being able to read/write.
  • a file watcher (inotify) to watch for edits on the file
  • fork into $EDITOR or whatever env var we use for this
  • copy the file back when it changes, asking for auth if needed. I am not sure how to ask for auth while an editor is potentially occupying the terminal session.
  • terminate the shim when the editor process stops, removing the temporary file
• Alternatively to inotify, the final move could happen when the editor closes and before the shim exits. The problem here: If you "save" in the editor, it will be saved to some temporary location and not actually be saved to hard disk before the last authentication. If that last authentication fails (e.g. because typo in the password), all the work is gone, despite the editor suggesting it was saved.

Of course if the editor or the password helper are not displayed in terminal but actual gui, this problem goes away. Same goes if you have persistent auth and can save without retyping a password. This is mostly a concern with headless systems running impersistent auth.

It basically boils down to "how do i get a password while in editor" and "where do i put the temporary file", and persistent auth will be somewhat impossible.

[LordGrimmauld]

I am getting somewhere.
run0 -u $(whoami) --property=ReadWritePaths="/tmp/rootfile" --property=CapabilityBoundingSet=CAP_DAC_OVERRIDE --property=AmbientCapabilities=CAP_DAC_OVERRIDE bash -c "echo mrrp > /tmp/rootfile" does allow editing a file without crazy increased privileges.

That said, some editors (like helix) refuse to save to a path which is supposedly read-only, even if the permission to write to the file does technically exist. And full CAP_DAC_OVERRIDE is still more permissions than i would like for this, but it is a step in the right direction. It certainly doesn't allow a rogue process to write to /proc/<pid>/fd/<fd> of the editor process, which was a concern i had with unprivileged editors editing privileged files. Its still something worth pursuing i think. Maybe just requires patching helix so it saves to a file if it has caps...

[LordGrimmauld]

Opened helix-editor/helix#14999 to hopefully get that one fixed

[LordGrimmauld]

systemd/systemd#35848 is also something to watch out for, then we maybe get an option that doesn't involve CAP_DAC_OVERRIDE

[LordGrimmauld]

Currently, if i want to avoid CAP_DAC_OVERRIDE:

• fork into privileged "daemon" and unprivileged "editor" processes.
• daemon execs into run0 /proc/self/exe --daemon <child pid>
• if run0 fails, the child dies without doing anything
• if run0 succeeds, the daemon copies the privileged file to a path in /tmp
• daemon sets up fanotify
  • bails if any process not passed as the pid on command line to the daemon touches the privileged file
  • writes the contents of the privileged file back to the original location on save
• daemon passes the path to the unprivileged editor process
• editor process execs into $EDITOR /tmp/<file>
• daemon waits for the child to exit

The issue i have with this approach: While it effectively prevents other processes from editing privileged files, it does not stop them from reading privileged files, because the file is still in /tmp. I can maybe disallow open except for that one pid though.

I am not sure whether i can just open a file descriptor in the daemon and pass that to the editor via $EDITOR /proc/self/fd/<fd>, but that too doesn't work because helix doesn't like writing to /proc/<pid>/fd/<fd> either. SCM_RIGHTS would come to mind, but not sure how well that goes.