<div dir="ltr">Hello,<br><div><div><div class="gmail_extra"><div class="gmail_quote">2017-05-14 15:36 GMT+02:00 chinmoy ranjan <span dir="ltr"><<a href="mailto:chinmoyrp65.gsoc@gmail.com" target="_blank">chinmoyrp65.gsoc@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I am a Google Summer of Code student working with KDE on the project "Polkit support in KIO[1]". The goal of this project is to enable KIO (this library provides file management functions in KDE softwares) to perform file handling operations with escalated privilege. This way the user can perform file handling operations in root owned location without having to start the whole application as root.<div>My approach[2] involves using the KAuth library(authentication framework for KDE) to create separate polkit actions for each file handling operation, like delete, copy, symlink, rename etc. One of the behavioural changes that is expected is when a user authenticates himself for a polkit action, say delete, he should be able to perform other actions , like  copy or symlink, during the time period when privileges are escalated for a while without having to provide his credentials.</div><div>So in pursuit of this I found the imply annotation in the reference manual of polkit. I used it in my PoC patch[3] (I directly modified the policy file) and it did produced the desired behaviour. When I authenticated myself for the delete operation, other actions like symlink were unlocked as well for a while. In other words it solved my little problem.</div><div><br></div><div>Now this is my first time working with polkit. So my doubts are,</div><div>1> Is this the actual work of imply annotation, i.e, to unlock(if I am putting it correctly) other actions after authenticating for one action? Although it is mentioned in the reference manual that it unlocks multiple actions from distinct mechanisms but a little clarification would help.</div></div></blockquote><div><br></div><div>Link has already pointed out the man page paragraph. If you want to know how it is implemented, see src/polkitbackend/polkitbackendinteractiveauthority.c: "if (!checking_imply)".<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2> If its not the purpose of the imply annotation then what is it for? And what can I use in my project?</div></div></blockquote><div><br></div><div>Generally it is used when there <i>is</i> a good reason to make the actions granular, but also quite common for a user to want to authorize a set of them at the same time.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>3> If imply annotation is indeed suitable for my project then I will have to add the support for annotations in KAuth library. In that case is there any guideline or specification that I must comply with?</div></div></blockquote><div><br></div><div>Not much more than the man page paragraph.<br></div></div><br></div><div class="gmail_extra">From the above description, though, I would recommend thinking about whether the different actions your KIO backend are actually distinct privileges; e.g. copy/symlink/rename are very likely equivalent in power (they allow the user to become unrestricted root), so there is little point in separating them.<br><br>And if you are considering using the “imply” annotation to allow all of the actions whenever any one is authorized, well, then they are <i>structurally</i> equivalent. It seems much simpler to me to have a single “modify the filesystem in arbitrary ways” action shared for all of the operations, making “imply” completely unnecessary.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Or, perhaps, at most, one “read anything” action and one “read and modify anything” action, with the read-write one implying the read-only one (but <i>not</i> the opposite).<br></div><div class="gmail_extra">   Mirek<br></div></div></div></div>