I think it's time to retire pam_console from the default configuration.
For device permissions, we already have the hal/consolekit support which should be use.
The following packages place the following files in /etc/security/console.perms.d, and would need modified to work with HAL/CK:
barry-libs: /etc/security/console.perms.d/10-blackberry.perms (quantumburnz) pam: /etc/security/console.perms.d/50-default.perms (tmraz) rainbow: /etc/security/console.perms.d/51-rainbow.perms (kantrn) em8300: /etc/security/console.perms.d/60-em8300.perms (heffer) jfbterm: /etc/security/console.perms.d/60-jfbterm.perms (mtasaka) thinkfinger: /etc/security/console.perms.d/60-thinkfinger.perms (?) svxlink-server: /etc/security/console.perms.d/90-svxlink.perms (lucilanga) vdr: /etc/security/console.perms.d/95-vdr.perms (scop) piklab: /etc/security/console.perms.d/icd2.perms (chitlesh) piklab: /etc/security/console.perms.d/pickit1.perms (chitlesh) piklab: /etc/security/console.perms.d/pickit2.perms (chitlesh)
I'd be willing to chip in to get these fixed, it shouldn't be that hard.
The second part of pam_console is that it provides the gating information for userhelper. There are many more apps that use this, and it's a more involved port to get them to use PolicyKit, or a similar framework. However, I don't see why we couldn't just port pam_ck_connector.so to drop the lock file in /var/run/console, and then usermode/userhelper can just work the same, without having to have a second extraneous pam module. We can then work on porting the other apps at our leisure.
Opinions?
Bill
On Fri, Jan 16, 2009 at 03:31:29PM -0500, Bill Nottingham wrote:
The second part of pam_console is that it provides the gating information for userhelper. There are many more apps that use this, and it's a more involved port to get them to use PolicyKit, or a similar framework. However, I don't see why we couldn't just port pam_ck_connector.so to drop the lock file in /var/run/console, and then usermode/userhelper can just work the same, without having to have a second extraneous pam module. We can then work on porting the other apps at our leisure.
Opinions?
I don't have much opinion on that, but I don't really get how pam_ck_connector goes in the picture. Currently it is not used by anything but login, since the ConsoleKit session opening is done either directly by the dm (kdm and gdm), or at the X session start, using ck-xinit-session (at least xinit does so, and xdm/slim/vnc/nx would do so once https://bugzilla.redhat.com/show_bug.cgi?id=452156 is resolved).
-- Pat
Patrice Dumas (pertusus@free.fr) said:
I don't have much opinion on that, but I don't really get how pam_ck_connector goes in the picture. Currently it is not used by anything but login,
It doesn't necessarily have to be in pam_ck_connector - it could be in the daemon itself.
Bill
Bill Nottingham <notting <at> redhat.com> writes:
I think it's time to retire pam_console from the default configuration.
For device permissions, we already have the hal/consolekit support which should be use.
That may well be correct, but I have no idea how to use hal/consolekit. I suspect few Fedora users do. Try polling your question on fedoraforum, and see what those results tell you. I recently posted a question there about configuring alsa permissions for mpd and the answer I got there was pam_console. Mind you, I am ready and willing to learn the brave new hal/consolekit way of things. I looked for docs and examples for hal/consolekit, and found nothing relevant to my use case.
Bottom line: before you blow away pam_console, please spend some time doing education (e.g., documenting) and outreach (e.g., responding on fedoraforum) about the new proper way of doing things that accommodates 80% of the existing use cases. If you want to be thorough about it, consider the software (like mpd) in a few prominent third-party repos, too.
On Sat, Jan 17, 2009 at 01:43:10PM +0000, Jack Tanner wrote:
Bill Nottingham <notting <at> redhat.com> writes:
I think it's time to retire pam_console from the default configuration.
For device permissions, we already have the hal/consolekit support which should be use.
That may well be correct, but I have no idea how to use hal/consolekit. I suspect few Fedora users do. Try polling your question on fedoraforum, and see what those results tell you. I recently posted a question there about configuring alsa permissions for mpd and the answer I got there was pam_console. Mind you, I am ready and willing to learn the brave new hal/consolekit way of things. I looked for docs and examples for hal/consolekit, and found nothing relevant to my use case.
In fact, pam_console is already not used anymore for many devices, usb devices, for example. The switch has been done since a long time.
In my opinion it was not ready at all at that time (and still not ready), and not only because of lack of documentation, also because consolekit was used without proper integration, but I have rehashed that so much, it is not really needed to do it again.
Bottom line: before you blow away pam_console, please spend some time doing education (e.g., documenting) and outreach (e.g., responding on fedoraforum) about the new proper way of doing things that accommodates 80% of the existing use cases. If you want to be thorough about it, consider the software (like mpd) in a few prominent third-party repos, too.
Are you sure that mpd is relevant here? Isn't it higher layer than pam_console/hal...?
Even before doing education, talking with other about the design, how it integrates with pam, xdmcp, X and so on and so forth would have been even more important, and it wasn't done right, in my opinion.
-- Pat
On Sat, Jan 17, 2009 at 09:07:02PM +0000, Jack Tanner wrote:
Patrice Dumas <pertusus <at> free.fr> writes:
Are you sure that mpd is relevant here? Isn't it higher layer than pam_console/hal...?
All I can tell you is that for mpd to be able to use /dev/sound, I had to set /dev/sound permissions via console.perms.d .
I see. Indeed, there needs to be some interaction with hal/* to set the acls/permissions differently.
-- Pat
Jack Tanner (ihok@hotmail.com) said:
For device permissions, we already have the hal/consolekit support which should be use.
That may well be correct, but I have no idea how to use hal/consolekit. I suspect few Fedora users do. Try polling your question on fedoraforum, and see what those results tell you.
How is positing a change in underlying, not-user-visible-at-all, system infrastructure to a user's forum a worthwhile endeavor? After all, the change to set sound device permissions from HAL was done years ago.
I recently posted a question there about configuring alsa permissions for mpd and the answer I got there was pam_console. Mind you, I am ready and willing to learn the brave new hal/consolekit way of things. I looked for docs and examples for hal/consolekit, and found nothing relevant to my use case.
http://people.freedesktop.org/~david/hal-spec/hal-spec.html#access-control
Examples are in /usr/share/hal/fdi/policy/10osvendor - look at 00-thinkfinger.fdi, or 20-acl-management.fdi. It's not necessarily the most well documented interface, but it should be stable.
Bill
Bill Nottingham <notting <at> redhat.com> writes:
How is positing a change in underlying, not-user-visible-at-all, system infrastructure to a user's forum a worthwhile endeavor? After all, the change to set sound device permissions from HAL was done years ago.
It's still visible to this user. Even though sound device permissions are set through HAL *by default*, pam_console is still a perfectly serviceable alternative. Now, you're saying you want to take this alternative away. That places the onus on you to make this transition bearable. (I'm not arguing against hal/ck on technical merits, just their practical ease-of-use today.)
http://people.freedesktop.org/~david/hal-spec/hal-spec.html#access-control
Examples are in /usr/share/hal/fdi/policy/10osvendor - look at 00-thinkfinger.fdi, or 20-acl-management.fdi. It's not necessarily the most well documented interface, but it should be stable.
Wow. That's a lot of stuff to wade through. How about a tutorial, or a "cookbook"? I don't have a 00-thinkfinger.fdi, that's probably a Thinkpad-only file.
Jack Tanner (ihok@hotmail.com) said:
How is positing a change in underlying, not-user-visible-at-all, system infrastructure to a user's forum a worthwhile endeavor? After all, the change to set sound device permissions from HAL was done years ago.
It's still visible to this user.
If the permissions aren't set properly for the logged-in user, that's a *bug*, not a user-visible change that says something about the underlying details.
Even though sound device permissions are set through HAL *by default*, pam_console is still a perfectly serviceable alternative.
Only in the sense that you now have two disparate systems trying to control access to the same devices. That will never work well, and it's best to eliminate any confusion.
Bill
Bill Nottingham <notting <at> redhat.com> writes:
Even though sound device permissions are set through HAL *by default*, pam_console is still a perfectly serviceable alternative.
Only in the sense that you now have two disparate systems trying to control access to the same devices. That will never work well, and it's best to eliminate any confusion.
You're concerned about the corner cases. I'm concerned about my use case. To say that "it won't ever work well" is wrong, since it works fine for me now. What you call "eliminating confusion" I call "throwing out the baby with the bathwater."
I'm not even saying don't throw out the bathwater. I'm just asking how this baby should swim in the new bathwater. (Talk about a tortured baby, er, metaphor.) :)
Jack Tanner (ihok@hotmail.com) said:
You're concerned about the corner cases. I'm concerned about my use case. To say that "it won't ever work well" is wrong, since it works fine for me now. What you call "eliminating confusion" I call "throwing out the baby with the bathwater."
Having never played with mpd, what's the specific usage case you're looking for? (i.e., when X happens, the devices should be writable by entity Y)
Bill
On Mon, Jan 19, 2009 at 4:24 PM, Bill Nottingham notting@redhat.com wrote:
Jack Tanner (ihok@hotmail.com) said:
You're concerned about the corner cases. I'm concerned about my use case. To say that "it won't ever work well" is wrong, since it works fine for me now. What you call "eliminating confusion" I call "throwing out the baby with the bathwater."
Having never played with mpd, what's the specific usage case you're looking for? (i.e., when X happens, the devices should be writable by entity Y)
mpd likely wants to install a rule that says "this device should *always* be accessible by this uid". Also, it should start pulse internally.
Colin Walters <walters <at> verbum.org> writes:
On Mon, Jan 19, 2009 at 4:24 PM, Bill Nottingham <notting <at> redhat.com>
wrote:
Having never played with mpd, what's the specific usage case you're looking for? (i.e., when X happens, the devices should be writable by entity Y)
mpd likely wants to install a rule that says "this device should *always* be accessible by this uid". Also, it should start pulse internally.
That's exactly the use case. The mpd daemon runs all the time, no matter who is doing what at the console. While it's running, it should always be able to play audio. I'm not sure about Colin's point about starting pulse internally... mpd does have an optional pulseaudio sink, but I use it with an alsa sink.
Jack Tanner wrote:
It's still visible to this user. Even though sound device permissions are set through HAL *by default*, pam_console is still a perfectly serviceable alternative. Now, you're saying you want to take this alternative away. That places the onus on you to make this transition bearable. (I'm not arguing against hal/ck on technical merits, just their practical ease-of-use today.)
The point is that users shouldn't be murking with pam_console or HAL permissions at all. They shouldn't have to. It's the packagers' job to make the permissions be correct out of the box.
Kevin Kofler
On Mon, Jan 19, 2009 at 8:11 AM, Bill Nottingham notting@redhat.com wrote:
Examples are in /usr/share/hal/fdi/policy/10osvendor - look at 00-thinkfinger.fdi, or 20-acl-management.fdi. It's not necessarily the most well documented interface, but it should be stable.
I'm still not sure how I expose my own device authorization policy so that it appears in the authentication guis.
The real win is being able to write the policy and package it up, so that its exposed via the gui tools so users don't have to hack hal policy directly that can use the authentication guis or the polkit-* cmdline tools to do authorization grants in the scope of the package-specific policy definition.
-jef
On Sat, 2009-01-17 at 13:43 +0000, Jack Tanner wrote:
Bill Nottingham <notting <at> redhat.com> writes:
I think it's time to retire pam_console from the default configuration.
For device permissions, we already have the hal/consolekit support which should be use.
<snip>
Bottom line: before you blow away pam_console, please spend some time doing education (e.g., documenting) and outreach (e.g., responding on fedoraforum) about the new proper way of doing things that accommodates 80% of the existing use cases. If you want to be thorough about it, consider the software (like mpd) in a few prominent third-party repos, too.
The problem is that a daemon shouldn't be talking to what should be session devices. mpd won't work with PulseAudio, and it won't work with HAL/CK permissions.
The maintainers would be better off adding hacks to set the permissions on the audio devices in the startup scripts.
Bastien Nocera <bnocera <at> redhat.com> writes:
The problem is that a daemon shouldn't be talking to what should be session devices. mpd won't work with PulseAudio, and it won't work with HAL/CK permissions.
mpd has a special sink for PulseAudio, if you choose to use it that way. PulseAudio is neat, but it uses too much CPU on my little old PC, so I've removed it. mpd gets along with ALSA just fine, and I can give it permissions via console.perms.d just fine. If you take away my ability to do that, please explain how to grant those same permissions via hal/ck.
The maintainers would be better off adding hacks to set the permissions on the audio devices in the startup scripts.
Sure, that'd be fine. Still, please explain how to set those. hal/ck is far too underdocumented for average users (and far too important to remain that way).
On Friday 16 January 2009, Bill Nottingham wrote:
I think it's time to retire pam_console from the default configuration.
[...]
em8300: /etc/security/console.perms.d/60-em8300.perms (heffer) vdr: /etc/security/console.perms.d/95-vdr.perms (scop)
[...]
I'd be willing to chip in to get these fixed, it shouldn't be that hard.
Thanks in advance. I'm pretty clueless wrt hal/consolekit but do know how vdr (which I maintain and use all the time) and em8300 (which I used to maintain and do still use all the time with vdr) should work. So here goes an explanation - if you can help out with these, maybe it'll serve as a good education session for myself and others here:
em8300 is a hardware MPEG decoder. Locally logged in users should be able to use it - I guess the same use cases as for DVB cards apply to it.
vdr is a daemon providing PVR functionality. It is run as a service, with a dedicated unprivileged system user account, needs to be able to use at least DVB devices without interference even if people log in locally to the box and log out, and also after boot without anyone logging in. Depending on the configuration and available plugins, it should also have similar access to the em8300 devices, serial ports, input/event devices and optical drives, possibly other devices as well. Ditto the other way around - the configuration shouldn't prevent locally logged in users from using these devices (obviously in case they're not in use by vdr but I suppose that's off topic).
Both em8300 and vdr currently use the "video" group, udev rules and a console.perms.d snippet to get the desired behavior. IIRC the only purpose of the console.perms.d snippet in both was to prevent pam_console from fiddling with the device permissions so that vdr could no longer use them when people logged in/out and/or to prevent pam_console from overriding the permissions set in udev rules by duplicating the rules in the console.perms.d snippet. (Oh, BTW, looks like the vdr one still contains some event/input references that should have been moved to the vdr-remote package which is a plugin through which vdr may use those devices.)
So... where do we start?
-
Bastien Nocera -
Bill Nottingham -
Colin Walters -
Jack Tanner -
Jef Spaleta -
Kevin Kofler -
Patrice Dumas -
Ville Skyttä