On Tue, 24 Oct 2006, Maxim Sobolev wrote:
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
OK, in this particular case I am trying to run su(8) binary compiled for
FreeBSD/ia32 on FreeBSD/amd64 system (FreeBSD 6.2 but this doesn't really
make any difference since the code is the same).
Since all audit syscalls in freebsd32 emulation layer are redirected to
nosys() any attempt to invoke such syscall results in both ENOSYS errno
*and* SIGSYS signal delivered to the process in question. The latter kills
the process without giving it any chance to handle ENOSYS.
So the actual bug here is that there's no compat32 definitions for the
audit system calls. I have a suspicion that we may need compat32 wrappers
in some cases, but you could start by simply exposing the audit system
calls in compat32 by changing UNIMPL to STD (or MSTD in RELENG_6)?
Shouldn't unimplemented syscall have the same semantics in binary
compatibility mode and in native mode (i.e. ENOSYS, but not SIGSYS)? That's
my biggest confusion. Why do we get just ENOSYS in native mode when audit is
not in, while ENOSYS+SIGSYS in compatibility mode?
The method by which the distinction between ENOSYS+SIGSYS and plain ENOSYS is
determined is in the implementation of the system call. If a system call is
flagged as unimplemented (i.e., you never hit the function implementing it),
you get SIGSYS+ENOSYS. If you enter the stub, you get ENOSYS. So the problem
is that the compat code doesn't enter the stub, so never gets to the ENOSYS
path. A casual glance at the system call arguments for audit suggest that
wrappers aren't needed (no pointers embedded in structure arguments), so
simply marking them as implemented will likely work.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
