> > SIGCAP should be catchable IMHO. A program should be able to articulate
> > why it doesn't work (I've spent the WE debugging lpd, it has useful
> > debugging messages as "Job transfer failed" even with -D10.)
>
> What I was saying is, if you kill things with a signal when capabilities
> fail, this signal should default to killing the process. Then
> non-capability-aware stuff would just die when someone tried tricks on it.
> Not the best behaviour, but possibly preferable. I don't know if the
current
> behaviour is a signal or simply to fail syscalls with permission denied.
>
> David.
Why not both? Why not return the syscall with failure (and appropriate
error code) AND send a signal. Signals are supposed to be async right? The
signal handler, for those cap aware future apps, could flip a flag that they
program can check after getting the failed syscall for more capability
specific information. Is this not doable? Or is it, just not desirable?
fwr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/