Hello, 2017-05-14 15:36 GMT+02:00 chinmoy ranjan <chinmoyrp65.g...@gmail.com>:
> 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. > 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. > 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. > > Now this is my first time working with polkit. So my doubts are, > 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. > 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)". > 2> If its not the purpose of the imply annotation then what is it for? And > what can I use in my project? > Generally it is used when there *is* 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. > 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? > Not much more than the man page paragraph. >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. And if you are considering using the “imply” annotation to allow all of the actions whenever any one is authorized, well, then they are *structurally* 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. 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 *not* the opposite). Mirek
_______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/polkit-devel
