NetBSD Problem Report #55764

From  Thu Oct 29 07:03:08 2020
Return-Path: <>
Received: from ( [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "", Issuer " CA" (not verified))
	by (Postfix) with ESMTPS id 413711A9239
	for <>; Thu, 29 Oct 2020 07:03:08 +0000 (UTC)
Message-Id: <>
Date: Thu, 29 Oct 2020 09:03:02 +0200 (EET)
From: (Kimmo Suominen)
Subject: per_user_tmp=YES not really usable
X-Send-Pr-Version: 3.95

>Number:         55764
>Category:       security
>Synopsis:       per_user_tmp=YES not really usable
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    security-officer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 29 07:05:00 +0000 2020
>Originator:     Kimmo Suominen
>Release:        NetBSD 9.1
System: NetBSD 9.1 NetBSD 9.1 (GENERIC) #0: Sun Oct 18 19:24:30 UTC 2020 amd64
Architecture: x86_64
Machine: amd64

	When using per_user_tmp=YES the /private/tmp/@ruid target is
	only created if a program calls setusercontext(3). This leaves
	programs that call setuid(2) (often followed by setgid(2) and
	initgroups(3)) without a /tmp directory, making various things
	fail (e.g. vi(1) needs /tmp).


	Try using any of the following from pkgsrc:

	- security/doas (fixed in doas-6.2p4nb3, where I switched it to
	  using setusercontext(3))

	- security/priv (waiting for the package maintaner to reply to
	  has a proposed fix)

	- security/sudo (the code was too convoluted for a quick patch)


	I know some people like to run "sudo su" -- this would be one
	reason to use it...

	It would be nice if the /private/tmp/@ruid target was created by
	some magic that made it work for setuid(2) as well.

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD:,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.