On Mon, May 15, 2017 at 8:40 PM, Miloslav Trmac <m...@redhat.com> wrote:
> 2017-05-15 16:56 GMT+02:00 chinmoy ranjan <chinmoyrp65.g...@gmail.com>: > >> > 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). >> > >> >> 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. >> >> Any thoughts on this? >> > Would that *actually* 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. > > And as I said, if the “imply” relations actually made all of the actions > equivalent, there would be *no effective granularity anyway*. The “imply” > relations *cannot be overridden by an administrator* 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, *you* need > to figure out how it works and whether it is sufficient in the use case. > > 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. > Mirek > 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 :( . Regards, Chinmoy
_______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/polkit-devel
