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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]