On Dec 19, 2007 11:05 AM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > I just don't see the conceptual difference between this device and > (say) a tape device. It seems as silly to give exclusive access to a > sound device based on an assumed proximity as it would with a tape > device that is likely to also be needed for scheduled jobs - and will > need exclusive access. And even stranger to tie access to some > particular window manager startup when many different ones may be > running along with processes not running under X and ones tunneled via > ssh instead of having a local session. Maybe there is no conceptual difference... which is why I think we're expressing frustration at the wrong piece of the new world order. Now that the default hal rules no longer "hide" internal disk drive partitions from gnome-volume-manager even if they are explicitly listed in fstab, I imagine this will also be a cause for frustration similar to the tape drive or the audio hardware scenario. Same goes for cd changers. I think the underlying problem is that advanced hardware access policy technology is advancing far more rapidly than local administrators are able to keep up with and its disrupting workflow that has been used for years. It's the bargain price of rapid innovation. I don't think there are insurmountable things going on, I just don't think we have a good enough understanding on how to use HAL/CK/PK to do local policy hardware access customizations, so we end up fighting the technologies instead of reconfiguration them. What we need to understand better as local sysadmins is how PolicyKit, ConsoleKit, and Hal can be re-configured to support well defined multuser environments scenarios, and limit how session related daemons get access to hardware. I don't know about you, but I learn best by having one or two tasked-based examples of how to reconfigure these things. For example having an example on how to write new configurations for these technologies that let me pre-emptively get access to a sound output for mpd in such a way that the user desktop PA daemon loses control would be a good read. Or how to reconfigure things so local tape/harddrive partitions are restricted from console user access so they can be used by automated backup services running out of cron. And I don't mean "find the hal policy definition file that came with F7 and drop it on your system." We need to actually have from scratch examples to work through, so we can understand the logic of constructing the configuration, not cookie cutter recipes to 'fix' things. I'll also say that I've seen the same sort of frustrations being expressed of selinux when it was introduced. The recent blog posts from Dan Walsh concerning how to actually reconfigure the selinux policy to get non-default things done have been exactly the sort of "re-learning" material that all the new technologies are going to need. The lock down of x-guest environment blog posts in particular have been good to help me think about actually using selinux to get something done and not just finding ways to disable selinux because its in the way. What we really need is this sort re-configure "Use CK/PK/Hal" to get something cool done. Unfortunately, as with the case of the selinux stuff, we really need the people who grok these technologies to produce this "re-learning" material, because the rest of us are just completely and utterly lost and are going to continue to work around these technologies instead of attempting to use them. Questions for the future. Can we develop drop-in configurations to replace the default configs for CK/PK/Hal which provide a better starting point for defined multi-user usage cases? Can we develop graphical tools which help tweak those configs for local needs? Will this tie into sabayon? I would think there would be a compelling RHEL need to introduce some local admin-centric helper tools for local hardware access policy decisions, so local admins will start to reach for the new technology as a solution instead of fighting it by just trying to turn it off or work around it. -jef"And by we.. I mean not me."spaleta -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
