Hi Florian, On 8 November 2017 at 07:24, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > On 11/07/2017 09:35 PM, Michael Kerrisk (man-pages) wrote: >> >> This change broke my code that was doing seccomp filtering for the >> open() system call number (__NR_open). The breakage in question is not >> serious, since this was really just demonstration code. However, I >> want to raise awareness that these sorts of changes have the potential >> to possibly cause breakages for some code using seccomp, and note that >> I think such changes should not be made lightly or gratuitously. > > > I have the opposite view: We should make such changes as often as possible, > to remind people that seccomp filters (and certain SELinux and AppArmor > policies) are incompatible with the GNU/Linux model, where everything is > developed separately and not maintained within a single source tree (unlike > say OpenBSD). This means that you really can't deviate from the upstream > Linux userspace ABI (in the broadest possible sense) and still expect things > to work. > > I know that people like to slap seccomp filters on everything today, but > without careful examination, that is likely to introduce bugs (particularly > on rarely used code paths). It can also cause the process to switch to > legacy interfaces with known issues (e.g., reading from /dev/urandom instead > of getrandom, without waiting for the kernel to signal initialization of the > pool). Thanks. The above is a good summary of the counterpoints to my initial argument. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
