On Thu, 2009-11-19 at 11:15 +0000, Richard Hughes wrote: > 2009/11/18 Chris Adams <cmadams@xxxxxxxxxx>: > > I would like to see this discussion separate from discussion about the > > current issue with PackageKit. > > That would be nice :) > > The problem is who to target. If you call Fedora a desktop distro, > then it makes perfect sense for local users to be able to shutdown the > computer, suspend, change the system clock and install clipart without > passwords, as long as it's done in a secure way. > > If you call Fedora a server OS, then it shouldn't be shipping > PackageKit at all, and should have most of the PolicyKit > authentication actions defaulting to no. > > So obviously we need some middle ground. I guess if the spins > "personalise" the package set then they should also personalize the > security defaults. e.g. a server spin would not include PackageKit at > all, and default to not letting users change the time. A desktop spin > would allow the desktop user to do most things without a administrator > password. The tricky part is deciding a default policy that is > suitable for all the people using Fedora, which honestly, I think is > impossible. It seems to me that the way to proceed here isn't to worry about different classes of Fedora installations, but rather to think about different classes of *users*. There may be a few machines where nobody is trusted to install signed packages without typing in the admin password again; luckily PolicyKit is a very configurable framework. But most cases, things separate pretty cleanly into: - People who are assumed to know what they are doing (parents, the departmental IT guy, etc.) - People who don't get to reconfigure the machine (children, students, etc.) By having that two part policy, and having the straightforward user configuration GUI that we've been wanting for years, I think we cover almost everything. And we don't have to ask the user at install time a question that they can't answer: "do you want your machine to be safe or to be convenient?" - Owen -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
