at_console

[Tom Parker]

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 
nodes.

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 
NetworkManagerInfo example.

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.

Tom Parker