From owner-cvs-all Tue Sep 4 12: 7:48 2001 Delivered-To: cvs-all@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 75AEA37B405; Tue, 4 Sep 2001 12:07:36 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f84J7ZX20069; Tue, 4 Sep 2001 13:07:35 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f84J7Yh37084; Tue, 4 Sep 2001 13:07:34 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200109041907.f84J7Yh37084@harmony.village.org> To: Ruslan Ermilov Subject: Re: cvs commit: src/usr.bin/at panic.c privs.h Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org In-reply-to: Your message of "Tue, 04 Sep 2001 21:01:12 +0300." <20010904210112.F17754@sunbay.com> References: <20010904210112.F17754@sunbay.com> <20010904204423.D17754@sunbay.com> <20010904192252.G1669@sunbay.com> <200109041615.f84GFpx76144@freefall.freebsd.org> <200109041620.f84GKZh35512@harmony.village.org> <20010904192252.G1669@sunbay.com> <200109041730.f84HUPh36129@harmony.village.org> <20010904204423.D17754@sunbay.com> <200109041748.f84Hmkh36422@harmony.village.org> Date: Tue, 04 Sep 2001 13:07:34 -0600 From: Warner Losh Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010904210112.F17754@sunbay.com> Ruslan Ermilov writes: : > No, in FreeBSD's implementation. setreuid should never be used. : > : > Use seteuid() do do the switching. It will allow the library routines : > to drop and add privs better than setreuid(). : > : No. : : seteuid(neweuid) only sets (if permitted) the effective UID, it does not : change the saved UID (root in this case), thus the application does not : lose its ``setuid root'' privilege. setreuid does set the saved uid in some cases, which is what makes it unsuitable for security work, but see below. : : The seteuid() function sets the effective user ID of the current process. : : The effective user ID may be set to the value of the real user ID or the : : saved set-user-ID (see intro(2) and execve(2)); in this way, the effective : : user ID of a set-user-ID executable may be toggled by switching to the : : real user ID, then re-enabled by reverting to the set-user-ID value. : : Similarly, the effective group ID may be set to the value of the real : : group ID or the saved set-user-ID. : : The task: change ``setuid root'' process to ``setuid daemon'' process. : : Original: uid = joe, euid = root, svuid = root : : case 1. setuid(DAEMON): uid = DAEMON, euid = DAEMON, svuid = DAEMON : : Impossible to temporarily relinquish privileges to that of joe. : : case 2. seteuid(DAEMON): uid = joe, euid = DAEMON, svuid = root : : The process is still ``setuid root'', the call to seteuid(root) : will succeed. Ah. : case 3. setreuid(-1, DAEMON): uid = joe, euid = DAEMON, svuid = DAEMON : : Same as original, except s/root/DAEMON/. So you are wanting to make things behave as if they were setuid daemon? That's about the only possible case where setreuid is right. My appologies. I've seen far to much other setreuid abuse over the years where it was used to swap uid and euid. That would be a reasonable use of setreuid. I take it that cron needs to be root to start, but then should run normally at reduced privs with the ability to get back to joe? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message