<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 8:40 PM, Miloslav Trmac <span dir="ltr"><<a href="mailto:mitr@redhat.com" target="_blank">mitr@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="h5"><div class="gmail_quote">2017-05-15 16:56 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><p dir="ltr">> 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 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.<br>
><br>
> 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).<br>
>  <br></p>
</span><p dir="ltr">My initial plan was to have one single action to perform all of the file handling operations. But after bit of discussion with my mentor I decided upon giving the  user more fine-grain control. So instead of one generic action that can be easily enabled or disabled, the user can now control which action gets privilege, like one can create new files but can't delete them or a user can rename files owned by root but can't perform any other operation.</p>
<p dir="ltr">Any thoughts on this?<br>
</p>
</blockquote></div></div></div>Would that <i>actually</i> be more granular if any of the actions were root-equivalent? If it weren’t more granular, asking the users to do extra work per action would be just wasted, and pretending to users that the granularity matters could make them make incorrect security assumptions and think they are secure when they weren’t.<br><br></div><div class="gmail_extra">And as I said, if the “imply” relations actually made all of the actions equivalent, there would be <i>no effective granularity anyway</i>. The “imply” relations <i>cannot be overridden by an administrator</i> in the .rules files, at least not directly. Perhaps .rules can still affect the authorization of those actions, but if you want to rely on that in the design, <i>you</i> need to figure out how it works and whether it is sufficient in the use case.<br><br></div><div class="gmail_extra">IMHO, if there is any granularity to be had, it is not rename/delete; it is either the coarse read/write one, or ideally a system where the privileged access can be granted only to specific subdirectories — but polkit is fairly unsuitable for such an open-ended granularity, and per-directory access can be given using ACLs anyway, so polkit is unnecessary for that.<br></div><div class="gmail_extra">    Mirek<br></div></div></blockquote><div><br></div><div>Thanks for the input. I will rethink my approach. Also the previous was supposed to be sent to the mailing list and cc'ed to you. Looks like something went wrong :( .</div><div><br></div><div>Regards,</div><div>Chinmoy </div></div><br></div></div>