P.S. Perhaps my mistake is that I have blindly assumed that attempt to
invoke unimplemented syscall on native platform (i.e. ia32 binary
running on ia32 kernel) results in the same error condition as attempt
to invoke unimplemented syscall in binary compatibility mode (i.e. ia32
binary on amd64 kernel). If it is not, then the binary compatibility
layer should be fixed instead to match behavior of the native mode.
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.
-Maxim
Robert Watson wrote:
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
sobomax 2006-10-24 08:18:10 UTC
FreeBSD src repository
Modified files:
usr.bin/su su.c
Log:
Ignore SIGSYS when BSM is compiled in. Otherwise, attempt to invoke
su on
system that don't have audit framefork compiled into kernel or ia32
binary
on amd64 system will result in SIGSYS. There is one place in su.c
itself
where it tries to check for errno != ENOSYS, but it has been a nop
since su
does not catch SIGSYS anyway. There are few other places in libbsm,
where attempt to invoke audit syscal would result in SIGSYS if no audit
support is present in the kernel, so that the only reliable method for
now is to disable SIGSYS completely in the case when BSM is compiled
in.
In the long run, both direct invocation of audit-related syscalls and
libbsm should be made more intellegent to handle the case when BSM
is not
compiled into the kernel gracefully.
MFC after: 3 days
(provided re@ approval)
I have to admit being a bit puzzled by your commit. Since you didn't
bother to contact me with a bug report before committing this presumed
fix, I can only assume that you are entirely certain that what you're
describing is the case. However, since it appears not to be the case
on thousands of deployed HEAD and RELENG_6 machines, I have to wonder
whether you're hitting an edge case that needs further debugging and
discussion.
Alternatively, you booted a really old kernel with a relatively new
user space. And by really old, I mean RELENG_6 in March of this year,
or HEAD in February. How did you manage to log in, as login(1) also
invokes the same system calls unconditionally that su(1) calls?
Returning ENOSYS from a system call stub should not (and in my
experience, does not) generate SIGSYS. There are three common cases
for unimplemented system calls:
(1) The kernel doesn't recognize the system call. Return ENOSYS +
SIGSYS. If
a binary handles SIGSYS, it gets the ENOSYS return, otherwise, it
exits.
This occurs if the system call isn't listed in the system call
table, or
if it's listed but unimplemented. This is what happens if you
invoke a
random system call number, or a new system call on a really old
kernel.
(2) The kernel recognizes, but does not implement the system call, and
the
system call is one where error handling is possible. This occurs
when a
system call stub function returns ENOSYS. For example, the audit
code
contains conditionally compiled system call code that returns
ENOSYS if
AUDIT isn't in the kernel. This also occurs when compatibility
stubs are
inserted to allow forward compatibility.
(3) The kernel recognizes and implements the system call, but the
underlying
object doesn't implement the call. Return EOPNOTSUPP, ENOTSUP,
EINVAL,
etc. Typical examples are VFS system calls where the file system
doesn't
implement the operation, such as extended attributes, hard links,
etc.
The audit subsystem uses the second approach so that userland binaries
can detect that audit is not available and handle it properly
(typically by not configuring audit and generating audit events).
Notice that we merged audit system call stubs to RELENG_6 for
6.1-RELEASE so that the upgrade path to an audit-enabled userland in
6.2-RELEASE would be un-bumpy if the user didn't properly follow
proper upgrade instructions (kernel before user space).
So: could you confirm that what you're observing is happening and
provide specific specific debugging information? For example, your
commit message hand-waves at 32-bit binaries on amd64 -- perhaps there
is a bug in the handling of ENOSYS in the compat/freebsd32 system call
path. A casual reading of the system call code suggests that this is
not the case, but I don't think this is a case I have specifically
tested. If you're running a very old kernel (pre-February/March) with
a new user space, understand that that is not a supported
configuration that will break for other more subtle reasons, and
please back out this commit.
Thanks,
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
