D12291: Accept file descriptor only from root owned process
Oswald Buddenhagen
noreply at phabricator.kde.org
Mon May 28 08:00:46 UTC 2018
ossi added inline comments.
INLINE COMMENTS
> chinmoyr wrote in fdreceiver.cpp:89
> > i don't see why that would be horrible
>
> I meant adding "acceptConnection = true;" after #warning would look weird. Obviously that's not even an issue and I shouldn't have mentioned it.
>
> There is a discussion[1] going on related to a similar change in ktexteditor. Because ktexteditor also uses polkit to save files in read-only location, one of the suggestions to improve this process, in case the owner of target is not root, was to either ignore the operation or drop privileges to owner/group of the directory. Now in KIO the kauth helper performs every operation as root. So if in future it is decided to do a privilege drop before performing any file operation on non-root targets then this change will likely be a hindrance. After considering the fact that this is also redundant, now I am not really feeling confident about this change. Just out of curiosity, I want to know (although I feel weird for asking this) what was your reason for accepting this patch?
>
> [1]: https://bugzilla.suse.com/show_bug.cgi?id=1033055#c13
i initially didn't notice the problem we're currently discussing.
but more generally: it's a second layer of security, just in case somebody accidentally f*cks up the perms of their runtime dir (not something to be particularly concerned about; you'd certainly have bigger problems in this case). it might also help detecting configuration problems (though for that you'd have to add reasonable error reporting). and if done right, it's (currently) harmless, and i didn't feel like arguing over it. but i myself would just drop it.
REPOSITORY
R241 KIO
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D12291
To: chinmoyr, #frameworks, dfaure, ossi
Cc: kde-frameworks-devel, ossi, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180528/8fdddfb9/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list