Package: udisks2
Version: 2.1.3-5
Severity: normal
Tags: upstream
udisks2's logic for whether I may do something to a device looks like this
pseudocode:
let requesting_seat = requesting process -> session -> seat
let device_seat = device -> seat
if (device_seat && requesting_seat && requesting_seat == device_seat) {
use a polkit rule like org.freedesktop.udisks2.filesystem-mount
(by default, requires either an active session or admin
authentication)
} else {
use a polkit rule like
org.freedesktop.udisks2.filesystem-mount-other-seat
(by default, requires admin authentication regardless)
}
This works poorly with the "user session" model used by dbus-user-session,
which the systemd/kdbus developers intend to be the only model supported
with kdbus. In that model, shared per-user services like gvfs and
gnome-terminal exist outside any particular login session, and are not
associated with a seat; the practical result is that while using
dbus-user-session, I always need to enter my password to mount a disk,
because gvfs' udisks backend is a child process of my `systemd --user`
rather than part of my GUI session.
One possibility for fixing this would be to change the pseudocode to this:
let device_seat = device->seat
if (device_seat) {
for session in requesting uid's active sessions {
if session->seat && session->seat == device_seat {
use a polkit rule like org.freedesktop.udisks2.filesystem-mount
return
}
}
}
use a polkit rule like org.freedesktop.udisks2.filesystem-mount-other-seat
with the justification that different sessions with the same uid do not
really represent a security boundary.
There is a bit of a subtlety here with active vs. inactive sessions:
if you have "fast user switching" on seat0, and this situation:
seat0
\- active (tty7): alice
\- inactive (tty8): bob
seat1 or ssh session
\- active: bob
then bob should not be able to manipulate seat0 devices (without admin
authentication) until alice finishes using seat0 and returns to bob's
(locked) session.
Thoughts?
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
