Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Oct 2006 10:10:08 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Maxim Sobolev <sobomax@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/usr.bin/su su.c
Message-ID:  <20061024094643.N37455@fledge.watson.org>
In-Reply-To: <200610240818.k9O8IATH022313@repoman.freebsd.org>
References:  <200610240818.k9O8IATH022313@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061024094643.N37455>