> it is done using a new system call named procfd_signal(). This system call operates on a file descriptor of a process; the previous discussions convinced Brauner that this is a solution preferred over an ioctl().
This is quite a pity! I do a lot of Python and Bash programming, and regular file write will be simple and easily supported.
ioctl would require some magic constants and arch dependence, but would still be relatively safe - there are no dangerous ioctl operators you can do on a open /proc directory entry, and ioctl has sane error reporting.
the "new syscall" path is the worst of them all -- I am literally two characters away from invoking all sorts of dangerous commands like "kill all processes", "shutdown machine" and so on.
The problem with an ioctl is that ioctls are not namespaced and so a buggy userspace program might end up being tricked into killing a process (if the ioctl overlaps).
ioctl also doesn't have exceptionally sane error reporting, especially when we're comparing it to syscalls.
In addition, this is the first step toward more generic procfds and for some other use cases ioctls are simply insufficient and it would be strange to have a mismash of both APIs.
> I am literally two characters away from invoking all sorts of dangerous commands like "kill all processes", "shutdown machine" and so on.
Can you explain what you mean? Syscalls are the least bad solution because we are guaranteed no reasonably buggy program will have used the syscall already.
Writing to a procfile would be significantly worse than either, but ioctls still have problems.
theamk|7 years ago
This is quite a pity! I do a lot of Python and Bash programming, and regular file write will be simple and easily supported.
ioctl would require some magic constants and arch dependence, but would still be relatively safe - there are no dangerous ioctl operators you can do on a open /proc directory entry, and ioctl has sane error reporting.
the "new syscall" path is the worst of them all -- I am literally two characters away from invoking all sorts of dangerous commands like "kill all processes", "shutdown machine" and so on.
cyphar|7 years ago
ioctl also doesn't have exceptionally sane error reporting, especially when we're comparing it to syscalls.
In addition, this is the first step toward more generic procfds and for some other use cases ioctls are simply insufficient and it would be strange to have a mismash of both APIs.
> I am literally two characters away from invoking all sorts of dangerous commands like "kill all processes", "shutdown machine" and so on.
Can you explain what you mean? Syscalls are the least bad solution because we are guaranteed no reasonably buggy program will have used the syscall already.
Writing to a procfile would be significantly worse than either, but ioctls still have problems.