Polkit support in KIO
Open, HighPublic

Description

Add polkit support to KIO using KAuth library. This would allow file management inside read-only directories.

The following steps are taken for gaining root access,

  1. Application starts a job with PrivilegeExecution flag.
  2. The job, after testing for this flag, sets two variables m_privilegeExecutionEnabled and m_operationType. The former variable is responsible for notifying the slave that job wants privileges to be elevated and the latter sets the type of operation which will be used with confirmation dialog.
  3. The job then sets the PrivilegeExecution flag in other sub-jobs which take KIO::JobFlags as argument. It also sets itself as the parent job for other sub-jobs it makes use of. This is also necessary for the confirmation dialog.
  4. Then control transfers to slave. It continues as usual and when certain operation fails it will call execWithElevatedPrivilege() method. This method will first check if the error was caused due to insufficient privileges and if it is indeed the case it will emit privilegeExecData() signal twice.
  5. First time it is for checking if the job actually wanted the privileges to be elevated. In this case once the signal is received by the job, value of m_privilegeExecutionEnabled (in case of SimpleJob it's parent job will be considered) is queried and if true ElevatePrivilege is sent back as reply.
  6. The next signal by the slave asks the job to show the confirmation dialog. For this purpose job calls tryAskPrivilegeOpConfirmation(). This method first checks for the parent job. It will continue checking till there is no parent job.
  7. Once the top-level job is obtained its tryAskPrivilegeOpConfirmation() method will be called and confirmation dialog is shown and if the user confirms then ActionConfirmed is sent back to the slave.
  8. If every step mentioned above succeeds then the slave will call the kauth helper and perform the action with elevated privilege.

Current Status

  • ChmodJob, DeleteJob, CopyJob, MkPathJob support performing file operations in read-only location.
  • KNewFileMenu is partially usable. "Create New -> Link to Application" and "Create New -> Link to Location" are not working
  • Dolphin's context menu will also work is all the writability checks are disabled

ToDo

  • Finalise approach
  • Add support for PrivilegeExecution flag in SimpleJob
  • Add unit tests for the changes till now
  • Make changes to` KpropertiesDialog` for "Create New -> Link to Application" and "Create New -> Link to Location" work properly
  • Make changes to FileUndoManager
  • Add the support for new slave to DropJob
  • Currently if jobs like copyjob are executed in a loop then multiple warnings are shown. Add a new job for the sole purpose of acting as a parent to those complex jobs created in loop.
chinmoyr created this task.Jul 22 2017, 9:45 AM
chinmoyr updated the task description. (Show Details)Jul 22 2017, 10:51 AM
dfaure added a subscriber: dfaure.Mon, Jul 24, 5:40 PM

About the last point: when are CopyJobs created in a loop? That surprises me, they can already deal with multiple source URLs, so one user operation should always result in a single CopyJob. That *is* the toplevel job.

The bit about emitting a signal twice sounds strange (maybe two signals is cleaner?) but I'll need to dig into it to understand better.

About the last point: when are CopyJobs created in a loop? That surprises me, they can already deal with multiple source URLs, so one user operation should always result in a single CopyJob. That *is* the toplevel job.

When renaming multiple files dolphin calls moveAs in a loop (case of multiple sources to multiple destinations).

@chinmoyr @dfaure: one thing we may have overlooked: how do we let clients know if they can set PrivilegeExecution ?

Currently the feature only works if:

  • KIO version is >= 5.38 (or whatever the version we will merge all the diffs in), and
  • OS is some Unix

So, if some apps use KIO and support Windows, they would probably have to implement some ifdefs checks.

I was thinking maybe we can extend all the supportsMoving()/supportsDeleting()/etc. KIO functions to return true if the underlying ioslave is polkit-enabled?

But does it hurt if PrivilegeExecution is set on Windows? Nothing different from today will happen, right? At least, that should be the goal.

Then it becomes simple: apps should set the flag if KIO >= 5.38 and the job is user-initiated (not e.g. the app copying some config file somewhere).

Oh, right. Then yes, it should be simpler than I was thinking. Cool!