Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jul 2019 15:48:39 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        Brooks Davis <brooks@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r350116 - head/lib/libc/gen
Message-ID:  <baeef32373d161d2b98c51d5fde8b828464aa27d.camel@freebsd.org>
In-Reply-To: <20190718214115.GA42117@spindle.one-eyed-alien.net>
References:  <201907182133.x6ILXu4k026793@repo.freebsd.org> <20190718214115.GA42117@spindle.one-eyed-alien.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2019-07-18 at 21:41 +0000, Brooks Davis wrote:
> On Thu, Jul 18, 2019 at 09:33:56PM +0000, Brooks Davis wrote:
> > Author: brooks
> > Date: Thu Jul 18 21:33:55 2019
> > New Revision: 350116
> > URL: https://svnweb.freebsd.org/changeset/base/350116
> > 
> > Log:
> >   Document that setmode(3) is not thread safe.
> >   
> >   In some circumstances, setmode(3) may call umask(2) twice to retrieve
> >   the current mode and then restore it.  Between calls, the process will
> >   have a umask of 0.
> 
> This race isn't especially serious, since it only occurs when
> security.bsd.unprivileged_proc_debug=0, but it's probably something to
> fix.  The easiest solution would probably be to implement a getumask()
> syscall.
> 

Or define a magic value to pass to umask(2) that means "return the old
mask without changing anything".  If umask() only cares about the low 9
bits and mode_t is uint16, that shouldn't be hard.

-- Ian




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