i'd append "(our setuid helper)" to that - i wondered for a moment why the limitation.

i wonder whether that shouldn't come with an unconditional acceptConnection = true; then - now the compilation succeeds, but it will fail to operate. given that the whole feature is redundant with moving the socket to a safe place (something you really should mention in the commit message), this seems like a rather pointless limitation.

I don't think making acceptConnection unconditionally true is a good idea. At least it will make this patch look horrible.
Since getsocketopt conforms to posix, how about we check for __ unix __ , and posix compliance instead of __ linux __ and upon failure inform the user to install a posix compliant libc?

i don't see why that would be horrible; as i pointed out multiple times already, this change is redundant. one correction, though: add a code comment here rather than extending the commit message.

getsockopt() is standard, but the actual options aren't. you could change the ifdef to SO_PEERCRED itself, but that wouldn't actually add any portability.

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.