[RFC] Syntax Proposal for Seccomp Filters in Upstart

David Gaarenstroom david.gaarenstroom at gmail.com
Tue Dec 18 16:29:27 UTC 2012


> Combined with the fact that, as mentioned, errno numeric values are not
> portable across architectures, I think it's better to just prohibit them
> outright rather than allow users to write jobs that will behave in
> unexpected manners.

I wouldn't advice using numeric values either, I'd only allow them as
fall-back. James' concern seems to be that syscall numbers might be
missing, and that might be just as much the case for errno numbers...
If someone likes to use a numeric value he *must* have a very good
reason for doing so and he should realize that that's
risky/non-portable/hackish. Again, Systemd does not support an errno
policy at all, no-one else is supporting an errno-string, Chromium .

However, I almost forget that the original motivation was to combine
the syntax for both the errno and trap policy. Trap sets "si_errno"
but it does not seem to be used like errno (but to communicate a
"reason" for trapping this particular syscall). Errno strings like
"EACCES" might make sense for trap, but other (numeric) values also
make sense.


>> I did look at arch/x86/syscalls/syscall_*.tbl and
>> include/asm-generic/unistd.h and arch/x86/include/asm/seccomp*.h
>> Anyway, just like with errno we could also allow a numeric value as
>> fall-back for future syscalls, I hope that addresses your concerns?
>
> syscall numbers are even less portable than errno.

True, but I'm trying to address James' concerns. It'd be only a
fall-back. Again, if someone likes to use a numeric value he *must*
have a very good reason for doing so and he should realize that that's
risky.

(I just noticed that on Ubuntu 12.04 LTS the x32 syscall-numbers are
also missing.)

Kind regards,
David G



More information about the upstart-devel mailing list