Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Jul 2014 16:32:38 +0200
From:      Mateusz Guzik <mjguzik@gmail.com>
To:        Matthew Fleming <mdf@FreeBSD.org>
Cc:        "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Mateusz Guzik <mjg@freebsd.org>
Subject:   Re: svn commit: r268087 - head/sys/kern
Message-ID:  <20140701143238.GD26696@dft-labs.eu>
In-Reply-To: <CAMBSHm-T1mjXXevOe=EMy2WuMsXE6Y=VoFBD-4mN_er0PB2b7w@mail.gmail.com>
References:  <201407010921.s619LXHL063077@svn.freebsd.org> <CAMBSHm-T1mjXXevOe=EMy2WuMsXE6Y=VoFBD-4mN_er0PB2b7w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 01, 2014 at 07:07:28AM -0700, Matthew Fleming wrote:
> On Tue, Jul 1, 2014 at 2:21 AM, Mateusz Guzik <mjg@freebsd.org> wrote:
> > Author: mjg
> > Date: Tue Jul  1 09:21:32 2014
> > New Revision: 268087
> > URL: http://svnweb.freebsd.org/changeset/base/268087
> >
> > Log:
> >   Don't call crcopysafe or uifind unnecessarily in execve.
> 
> I'm not sure the code works.
> 
> It gets a copy of the pointer p_ucred under the PROC_LOCK.  The
> PROC_LOCK is released before newcred = crdup(oldcred) is called.  Thus
> you may be copying an old version of the credentials if any of the
> other functions that modify them run in the meantime.
> 
> Maybe this can't happen because the process is single-threaded at the
> time and all the other sets of p_ucred come via a syscall.  I didn't
> look at all the functions in the kernel which set p_ucred.  But only
> in the case that none of them can run during do_execve this code would
> be safe.  In which case it at least deserves a comment indicating the
> code is violating the normal locking and safety on p_ucred.
> 

All other threads have to be blocked, otherwise there are more dangerous
races - for instance we support sharing file descriptor tables, so
execve makes sure to unshare the table (fdunshare()), which is
especially important for suid binaries. If other threads could execute,
they could fork off after fdunshare() and then have a table shared with
now privileged process.

That said, I can add appropriate comment + assertion at top of do_execve
later, just wanted to note the code was assuming that the process is left
alone prior to my changes.

> Also, what is the motivation to avoid the crcopy?  Is there a
> measurable performance impact?
> 

It's just a minor cleanup.

-- 
Mateusz Guzik <mjguzik gmail.com>



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