edit others user crontab, security bug

[Garrett Wollman]

<<On Thu, 1 Sep 2016 18:56:04 +0200 (CEST), Damian Weber <dweber at htwsaar.de> said:

> bsm/libbsm.h:#define    AU_USER_NAME_MAX        50

That's fine, since it means that the user name in an audit record
(i.e., output data) is bigger than what FreeBSD needs.

> netsmb/smb.h:#define SMB_MAXUSERNAMELEN 128

Not sure that this matters for anything.

> sys/param.h:#define     MAXLOGNAME      33              /* max login name length
>  (incl. NUL) */

This is the one that matters.

>  sys/sysctl.h:#define    USER_TZNAME_MAX         20      /* int: POSIX2_TZNAME_MA
>  X */

Not relevant.

>  limits.h:#define        _POSIX_LOGIN_NAME_MAX   9

This is the POSIX "minimum maximum" -- i.e., all POSIX systems must
support at least this value.

>  stdio.h:#define L_cuserid       17      /* size for cuserid(3); MAXLOGNAME, lega
>  cy */

Legacy interface that should not be used.

>  unistd.h:#define        _SC_LOGIN_NAME_MAX      73

Because we do not define LOGIN_NAME_MAX, portable applications are
required to use sysconf(3) to find out what {LOGIN_NAME_MAX} (i.e.,
the parameter, not the C-language macro) in the running system
actually is.  This is the "key" which allows them to retrieve that
value; it is just an arbitrary integer (could be an enum if we went in
for that sort of thing).

I see now that this was fixed by emaste@ yesterday (r305269).  I'm a
bit disappointed that it was done using MAXLOGNAME, but looking at the
way it's used in the code, fixing it to use the proper POSIX parameter
{LOGIN_NAME_MAX} would require significant restructuring, since the
arrays that are currently statically allocated would have to be
replaced with dynamic allocations.  There are other static limits in
this old code that should probably also be replaced, for safety, but
don't represent a problem currently.

-GAWollman