Date: Fri, 2 Sep 2016 22:31:06 -0400 From: Garrett Wollman <wollman@bimajority.org> To: Damian Weber <dweber@htwsaar.de> Cc: freebsd-security@freebsd.org, emaste@freebsd.org Subject: Re: edit others user crontab, security bug Message-ID: <22474.13802.335507.240401@hergotha.csail.mit.edu> In-Reply-To: <alpine.BSF.2.20.1609011847040.21761@isl-dw.htwsaar.de> References: <CA%2Bf9Cbu8q2KngxgAmZ8BrKYyYC5okDcMAs4nd=SJS6YpBMRJcQ@mail.gmail.com> <1472737438.3589865.712736753.5CFBB0DC@webmail.messagingengine.com> <alpine.BSF.2.20.1609011847040.21761@isl-dw.htwsaar.de>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Thu, 1 Sep 2016 18:56:04 +0200 (CEST), Damian Weber <dweber@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22474.13802.335507.240401>