Feature changed by: Lukas Ocilka (locilka) Feature #314778, revision 10 Title: Use polkit for YaST privilege management - openSUSE Distribution: Evaluation by engineering manager + openSUSE Distribution: New Priority Requester: Desirable Requested by: Dainius Masiliunas (greatemerald) Partner organization: openSUSE.org Description: At the moment of writing, YaST relies on having root privileges through a graphical sudo in order to view and carry out most tasks. However, there is no reason why simply displaying those tasks should be restricted like that. YaST should always be started with user privileges, and only ask for additional privileges when they are truly needed - when the selected tasks should be carried out. This can be achieved by using polkit. It also brings a lot of other benefits. Relations: - Discussion of the idea on the mailing list (url: http://lists.opensuse.org/yast-devel/2007-10/msg00024.html) - Feature in Bugzilla (url: https://bugzilla.suse.com/show_bug.cgi?id=1108424) + - Tracking at Trello (Internal) (url: + https://trello.com/c/Y6JN4SUY/2561-authenticate-yast2-with-polkit) Use Case: Users who do not have access to the root password currently also do not have access to a lot of functionality that does not actually require the password, such as searching for package information. Users that do administrative tasks are also subjecting the system to possible security risks by running YaST with full root privileges. Using polkit would increase security and prevent potential user mistakes. Business case (Partner benefit): openSUSE.org: Using polkit, the graphical interface of YaST would always be run as a normal user. That means that code that should not have elevated privileges - like GUI - would not run with them. More could be done without needing to enter the root password - package information query, printer setup, device information overview, reviewing network configuration options etc. In a restrictive environment, the system administrator could set certain tasks to be available for use by regular users, or to allow certain tasks to be run by certain users only. The authentication screen would provide more information about what tasks are about to be carried out for increased security. For instance, if a custom YaST module requests permission to modify the partition table, while it claims to only set up the date and time, it would be clear to the user that the module is either fraudulent or is malfunctioning. In order to not have to authenticate after every single change a module wishes to do, a global queue for the changes could be created (like what is shown by the /etc/sysconfig editor once its changes are to be applied). Once the global "apply" button is pressed, the user would be informed of what actions will be carried out and what privileges will be given to carry them out. Then, once the user confirms that by supplying a password, all the changes are applied. Discussion: #1: Hardy Heroin (jsnel) (2013-03-09 19:45:07) This is also one of Linus Torvalds' main objection with openSUSE, see for instance this article about it: http://www.theregister.co.uk/2012/02/29/torvalds_tantrum_opensuse/ Would be great if trivial tasks in openSUSE no longer require root. #2: Jiří Suchomel (jsuchome) (2013-07-08 14:36:39) This would require some major change in YaST architecture, that would be able to divide part that can be run by any user from the part run by privileged user only. There were some attempts already (e.g. Gloves project), but none was finished. #3: Dainius Masiliunas (greatemerald) (2013-08-12 18:35:51) (reply to #2) Really? It seems to me that it would just need a few privilege-awareness changes. Instead of presuming that each module runs as root, you instead queue up the changes that the module wants to do to the system, then pressing the Finish button asks for the password and applies the changes. The workflow stays pretty much the same, because that's already what most YaST modules do as it is. The only thing that is missing is a way to integrate the queue with polkit, and review the actions that each module wishes to take (so that it wouldn't always require a password when one is not needed, and would ask only for the necessary amount of privileges they need). Even without the extensive review, it would already be an improvement over what we have now, since at least the GUI would always run as the user, and not root, for added security and theme consistency with the desktop. -- openSUSE Feature: https://features.opensuse.org/314778