Re: svn commit: r350116 - head/lib/libc/gen
On Thu, Jul 18, 2019 at 09:41:15PM +, Brooks Davis wrote: > On Thu, Jul 18, 2019 at 09:33:56PM +, 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 make the KERN_PROC_UMASK sysctl work on the process itself even if security.bsd.unprivileged_proc_debug=0. This security sysctl is currently also lowering security. -- Jilles Tjoelker ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350116 - head/lib/libc/gen
On Thu, 2019-07-18 at 21:41 +, Brooks Davis wrote: > On Thu, Jul 18, 2019 at 09:33:56PM +, 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 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350116 - head/lib/libc/gen
On Thu, Jul 18, 2019 at 09:41:15PM +, Brooks Davis wrote: > On Thu, Jul 18, 2019 at 09:33:56PM +, 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. You can use pthread_suspend_all_np(3). ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r350116 - head/lib/libc/gen
On Thu, Jul 18, 2019 at 09:33:56PM +, 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. -- Brooks signature.asc Description: PGP signature
svn commit: r350116 - head/lib/libc/gen
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. Reviewed by: markj Sponsored by: DARPA, AFRL Differential Revision:https://reviews.freebsd.org/D20982 Modified: head/lib/libc/gen/setmode.3 Modified: head/lib/libc/gen/setmode.3 == --- head/lib/libc/gen/setmode.3 Thu Jul 18 17:55:13 2019(r350115) +++ head/lib/libc/gen/setmode.3 Thu Jul 18 21:33:55 2019(r350116) @@ -28,7 +28,7 @@ .\" @(#)setmode.3 8.2 (Berkeley) 4/28/95 .\" $FreeBSD$ .\" -.Dd February 22, 2015 +.Dd July 18, 2019 .Dt SETMODE 3 .Os .Sh NAME @@ -125,3 +125,10 @@ and .Fn setmode functions first appeared in .Bx 4.4 . +.Sh BUGS +The +.Fn setmode +function is not thread safe. +Files created in other threads while +.Fn setmode +is being called may be created with a umask of 0. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
