> I think that allowing the specification of an errno as a numeric rather than a > symbol should be avoided if possible. So, 'EACCESS' is fine, but allowing '13' > to represent nominally the same value is potentially ambiguous.
I'd allow a number as a fall-back, but I'd prefer the textual errno just as much as you do, but it may not cover all possible errno's. The seccomp BPF allows a larger scale of numeric values (0-0x1FFF as far as I know, beyond that seccomp gets weird even though there's room for an unsigned 16-bit value)... > Upstart supports running jobs from within a chroot environment. So imagine a > system running Upstart 1.7 but which hosts a chroot that uses Upstart 1.8. The > host environment only has knowledge of the system calls that the actual > running > kernel provides (ie libc and the kernel version and Upstart's seccomp handling > are all in sync). However, in the chroot, jobs may attempt to use a newer > syscall than is provided by the running kernel (since they may have been > developed on a non-chroot system with a newer kernel). > > So it sounds like you're proposing that the seccomp layer will identify the > unknown syscall and discard it? Normally the kernel will discard it since it does not know the syscall number. "syscall(320);" seems to return with -1 and set errno to 26 (ETXTBSY) for amd64. (I expected ENOSYS.) If you're using a syscall-number not yet known to an older kernel than the one the chroot is targeted for, that program is not going to run on that kernel, with or without a chroot. But if a seccomp rules denies unlisted syscalls, new syscalls will be denied even before handed to syscall, so it is treated differently...On the other hand if unknown syscalls are implicitly allowed (seccomp-filter start with "~") the "unknown" syscall number is approved, passed to the kernel and the kernel will handle it with an errno. I can imagine that when the kernel API changes, a program or libraries such as libc may first try to probe a syscall existence by passing the syscall-number and look at errno whether or not it failed or look at the kernel version and not even try... I'm going to have to find such an example first. And I don't know how likely the kernel is going to add new syscalls that really interfere and how soon these changes are supported by new software, I'll try to find out... I did look at arch/x86/syscalls/syscall_*.tbl and include/asm-generic/unistd.h and arch/x86/include/asm/seccomp*.h (which seem to be the only include files containing #defines for (x86 related) syscall numbers) and it seems these changed in the past: "__NR_kcmp" was added in linux-3.5 "__NR_process_vm_readv" and "__NR_process_vm_writev" were added in linnux-3.2 "__NR_sendmmsg" was added in linux-3.0 The __NR_kcmp is indeed unknown in Ubuntu 12.04LTS amd64, running a 3.6.10 kernel. Anyway, just like with errno we could also allow a numeric value as fall-back for future syscalls, I hope that addresses your concerns? Kind regards, David G -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
