palfrey at tevp.net
Sun Feb 6 15:12:30 PST 2005
A number of NetworkManager users (myself included) have been noticing
problems using NetworkManagerInfo due to the use of at_console in the
default NetworkManagerInfo dbus client policy. at_console, with it's
implicit reliance on the existence of pam_console (which certainly isn't
on Debian machines, and I'm unsure of how many non-Redhat machines have
it) appears to be therefore currently non-portable. I started to think
how this could be fixed, and came up with a number of ideas.
1) Persuade the major distributions (except Redhat which has done this)
to ship pam_console. This will run into issues with Debian certainly, as
some googling indicates some issues re: possible problems with various
users logging in/out and the uncertainity of who will own various device
2) Replace the current 'check for a /var/run/console/$username' with an
actual implementation of the pam_console logic i.e. check the user's
logged in terminal and see if they're a console user. This gets around
the Debian issues as we're not messing around with device node
permissions at all.
3) Replace with something else. Not sure what/how, this depends on how
useful 'user has a console' is as a authentication measure, and whether
we actually need something (possibly subtly) different. Ideas welcomed...
4) Scrap it completely, and we go back to only using group/user
permissions as before e.g. possibly using the 'plugdev' group for the
Just my 2p, but felt this might well be of use, and should hopefully at
least spark some discussion on this, which I felt had got to the point
of needing some help from DBUS people as opposed to just NetworkManager
people finding interesting workarounds to things that may well get
replaced/changed significantly later down the line.
More information about the dbus