In D17737#517736, @thiago wrote:

QFile::copy already implements FICLONE, sendfile() and Darwin's clonefile().

the patch definitely looks like a hack, but i'll leave the final judgment on that to thiago.

here too, it should be "ancestor" not "parent" for extra correctness.
amending the code comment is optional, too.

note that for extra correctness it should be "ancestor" not "parent".

i said "3rd line", not "3rd case". it's about the ancestry; see the other change.

the 3rd line is still wrong ...

right, threads, i didn't think of that. i suppose it might make sense to pthread_kill() from within kcrash to freeze the other threads, but that will be non-atomic, and i wonder whether it wouldn't have undesirable interactions with the attached debugger and/or exiting the process.

In D11235#395021, @croick wrote:

What do you mean? The (internal) debugger is a child of the debuggee.

commit message inverted here as well.

you got the parent-child ordering wrong in the commit message. ^^

will also need to wait for commit message update, like the other change.

In D11236#394363, @croick wrote:

Actually the point I removed does not seem to be true any longer. I'm almost certain, that the prctrl(PR_SET_PTRACER, ...) was not required until some time ago when starting DrKonqi as a fork. But now the internal backtrace is not working without. I cannot tell, when that started (currently using kernel 4.20).

mark handled issues as done here as well.

mostly minor issues left.

In D11236#393789, @ossi wrote:

detaching via double fork() "protects" the child process,

In D11236#393720, @croick wrote:

Actually it's only the internal process that creates the backtraces, that is a descendant of DrKonqi. All debuggers that are launched via the "Debug" button are processes on their own (to remain alive, even if DrKonqi already quit).

yay, i finally have "some" time for this. ^^

\o/
;)

this dependency tree is a mess. please remove deps to abandoned changes or unabandon what you actually still need, and linearize the history.

note that the commit message needs a minor adjustment now.

but so does using raw pointers. as the stl is available here anyway, it seems like the preferable abstraction layer.

why aren't you standardizing on std::string? that's cleaner than raw char pointers.
i know we discussed this before to some degree, but i don't remember the particulars.

did you make sure that this is the only place where SocketAddress is used?

as i certainly mentioned somewhere else already, this is redundant with putting the socket in a safe place. but fair enough ...

note that there are also unaddressed comments from previous rounds.

still needs update

not sure why; the changes are semantically separate.

that contradicts the comments i added to both reviews.

the idea is that you can do directory-based access controls on file-based sockets, while the abstract namespace has no controls.
otoh, only linux has the abstract namespace, and it supports peer credential verification as well, so this doesn't actually add any security afaict.
arguably, the patch still makes sense from a maintenance perspective, removing a redundant code path.
fwiw, i'd re-order this patch before the other one - it makes for smaller patches to first remove code and then refactor only what's left.

looks good, though technically speaking this still fixes two separate issues.

But i'm not sure if thats feasible.

In D9966#199979, @dfaure wrote:

Thiago: now it's ready for your review ;)

you *really* should use a whitelist. it's ok if that breaks some 3rdparty extractor; you'll get a bug report which you can properly evaluate.
you could go totally overboard and assign fine-grained syscall capabilities to individual extractors, but i can't really think of legitimate reasons why that would be necessary in this context.

yeah, but without knowing the root cause, your fix may be just wrong, or at least the comment/commit message may be misleading.
also, https://community.kde.org/Policies/Commit_Policy#Don.27t_commit_code_you_don.27t_understand

first try googling it; maybe there is even a response on stackoverflow (as so often happens).
then try posting it yourself to stackoverflow.
dunno whether such questions are welcome on the linux-kernel list, but if not, there might be other lists where it would fit.

please verify that this is in fact a kernel bug (include ml references), not something that should be expected for some weird reasons (compare the solaris path).
if this is a bug, does it actually affect released versions which are not being "upgraded away" on short notice? i wouldn't want a workaround for a bug that had a very short life span.