Description of problem: Version-Release number of selected component (if applicable): Fedara 12 (kernel 2.6.31.12-174.2.22.fc12.i686) How reproducible: always Steps to Reproduce: 1. Log in as regular user (no privileges) 2. Click on "Updates Available" icon 3. Apply updates [4. Click reboot button] Actual results: System updates without further ado. Expected results: User is prompted for root password. Additional info: This is an offshoot of Bug #534047, which was fixed in an update. That bug/"feature" allowed users to INSTALL software from trusted repositories. It was suggested at the end of that bug's discussion that this feature be disabled for updates as well. I cannot agree more! This bug is intended to open the discussion of this "feature" and eventually restore the "old" behavior of requiring anyone who wants to update software to be an administrator (or have the administrator's permission in the form of group membership). Before anyone asks, there ARE instances when one might not want to install the latest updates. Example: I used to use a kernel module built from outside the Fedora repositories (from NVIDIA) to run my display; the standard driver with Fedoras 8-10 did not do a very clean job some things. Every time a kernel update came through, I had to check whether the kmod-nvidia update was ALSO selected. If it was not, I'd have to delay the update until the driver was updated for the new kernel or my new kernel wouldn't be able to load the video driver! Now imagine my laptop was actually a multi-user OS in a computer lab (say in a high school or university) with people who could press the "update" button whenever they pleased. This could become a serious problem in a matter of minutes! Administrators expect that some things can break when they install updates, and are usually equipped to fix them if/when they do break. Regular users are usually not so equipped, and should therefore not have this permission unless it is explicitly granted to them.
This bug has been triaged Steven M. Parrish KDE & Packagekit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
> Before anyone asks, there ARE instances when one might not want to install the > latest updates. Sure, and that's why it's a policy choice, rather than hardcoded decision. You're free to change the default policy for your site easily using a PolicyKit pkla file.
(In reply to comment #2) > > Before anyone asks, there ARE instances when one might not want to install the > > latest updates. > > Sure, and that's why it's a policy choice, rather than hardcoded decision. > You're free to change the default policy for your site easily using a PolicyKit > pkla file. Yes, but the default policy now allows users to update the system, which they should not be able to do unless granted that permission. It's also not at all clear how one would disable the default behavior (I'll see what I can dig up on the PolicyKit pkla file front); this should be an option either during installation or on the update screen itself, preferably both. For example, a checkbox that says, "Allow unprivileged users to download/apply updates," and a dialog that asks for authentication if they change the status of that box!
I second Karl's view. The default policy should not allow updates by unprivileged users, since in the real world, updates can break systems, and only an user with administrative rights should decide whether to update or not to update. I have already expressed my concerns in a comment on Bug #534047 and also on the devel list.
(In reply to comment #4) > The default policy should not allow updates by unprivileged users... You forgot to add the important words "In my opinion"... In _my_ opinion as a maintainer, and designer, it's more important that updates are automatically installed and the system stays secure. If updates break working systems then the updates are broken, and should have been detected by the QA process. > This bug is intended to open the discussion of this "feature" and eventually > restore the "old" behavior of requiring anyone who wants to update software to > be an administrator... Bugzilla isn't a discussion forum. Bug get reported, debugged, fixed and then closed. If you want to discuss this then please use fedora-devel or bring the issue up with FESCO. As far as I'm concerned FESCO have already discussed this and come up with http://fedoraproject.org/wiki/Privilege_escalation_policy -- which PackageKit complies with 100%. I've already explained how you can change the defaults to your site policy (man PolicyKit). Remember, just because you don't agree with the defaults doesn't mean they are not good defaults. Fedora can't be suitable for everyone out of the box, sooner or later you're going to have to configure it for your site. Thanks.
Mr. Hughes, I am dismayed by your continued rudeness on this subject (I'm including your comments to the mother bug, #534047, as well). Here's my take on this (replace "take" with "opinion" if you so desire): most of us feel that we should have a say in whether the existing update/security policies on our machines change. When an update changes those security policies from what existed in the previous version, many would consider that change to be a bug. Perhaps it is a feature; if so, it is the developers' responsibility to provide a very straightforward way to undo that feature if the end user does not appreciate it. As such, however, I don't think that reporting such a change as a bug is inappropriate. My use of the word "discussion" WAS inappropriate, perhaps, but I do not think reporting this as a bug was inappropriate. "man PolicyKit" returns an error, by the way. Man "pklalocalauthority" provides some (very dense) instructions that may make it possible to undo this policy, but it's in no way obvious. Something obvious would be along the lines of a checkbox in the gpkapplication or a very clear statement in "man gpkapplication" (which currently doesn't exist) on exactly what to do to disable this feature without becoming an expert in the innards of PolicyKit. Please bear in mind that many users are not developers. I'm re-opening this bug. If you are unwilling to solve it, I humbly request that someone else be assigned to it.
I've given this a fair amount of thought, and I've decided to honor Mr. Hughes's decision to close this bug. I am, however, changing its status from "will not fix" to "not a bug," since that is more in line with the comments to date. My reasoning is as follows: this is definitely a change in behavior, and the effect is contrary to what I would expect Fedora-based systems to do. It is also contrary to how YUM, my preferred package management system, operates. However, it appears this WAS the intended practice, and it is therefore NOT a bug. This is therefore not the proper forum for this issue. I still do not think this is the right default behavior. I understand why "automatically download and apply updates" would be an acceptable default, though I would most likely remove this setting as soon as I found it was active. This is easily done via a checkbox on the "preferences" panel in the software updater, and I therefore understand why it COULD be the default. However, the default is to NOT automatically update, and instead leave the decision up to everyday, non-privileged users as to when and what to update. This seems illogical to me, but as was stated, this is not the forum for such grievances. In case anyone else wants to do the same thing I did (i.e., disable updating without authorization), here is what I've been able to piece together on how to deactivate this feature: Go to /var/lib/polkit-1/localauthority and enter any of the subdirectories below (20-org.d is supposed to be organization-level policies, 30-site.org is for site-level policies, 50-local is for the local machine, and 90-mandatory means ALWAYS GETS APPLIED AND OVERRIDES EVERYTHING ELSE [emphasis mine]). In one of those directories, create a file with a .pkla extension (any name will do), that contains the following: [NoUsersChangePackagesWithoutPassword] Identity=unix-user:* Action=org.freedesktop.packagekit.* ResultAny=auth_admin ResultInactive=auth_admin ResultActive=auth_admin This should restrict normal users (who aren't members of the "unix-administrators" policy group) from changing packages in any way. If you only want to restrict installs (the default), use "Action=org.freedesktop.packagekit.package-install"; if you want to restrict updates, I suspect "Action=org.freedesktop.packagekit.package-update" will work (though that's untested, at least by me). How I was supposed to generate the above file in a trivial way (i.e., not by browsing forums and copying other people's examples) is another issue entirely.... I apologize if I stepped on anyone's toes here. I do, however, prefer security-related things to not change when I upgrade from, say, Fedora 10 to Fedora 12. In that light, I encourage all developers to incorporate some GUI-based policy configuration manager into future Fedora releases. I recognize that all developers are only making changes that they think are best for Fedora, which I encourage them to keep doing. I also encourage them to be patient with those of us who object to those features (or think them to be bugs) and to provide such people with easy ways to undo those changes.
(In reply to comment #7) > How I was supposed to generate the above file in a trivial way (i.e., not by > browsing forums and copying other people's examples) is another issue > entirely.... We've got a new user account dialog in F13 which should make setting policy much easier.