Date: Thu, 10 May 2001 12:45:29 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: Kris Kennaway <kris@obsecurity.org>, audit@FreeBSD.ORG Subject: Re: ping6 fixes Message-ID: <20010510124529.C19855@sunbay.com> In-Reply-To: <Pine.BSF.4.21.0105090401450.12449-100000@besplex.bde.org>; from bde@zeta.org.au on Wed, May 09, 2001 at 04:20:44AM %2B1000 References: <20010508152816.A58026@sunbay.com> <Pine.BSF.4.21.0105090401450.12449-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 09, 2001 at 04:20:44AM +1000, Bruce Evans wrote: > On Tue, 8 May 2001, Ruslan Ermilov wrote: > > > On Tue, May 08, 2001 at 04:03:48AM -0700, Kris Kennaway wrote: > > [...] > > > + > > > + /* revoke root privilege */ > > > + seteuid(getuid()); > > > + setuid(getuid()); > > > > > > /* > > > optval = 1; > > > > I still think seteuid() here is superfluous, but see below. > > > > I've just checked that OpenBSD's setuid() behaves differently, > > as mandated by recent POSIX specs. The differences are as > > follows: > > This doesn't seem to be anything recent. I'll check again tomorrow > when I'm awake. Does POSIX now mandate _BROKEN^W_POSIX_SAVED_IDS? > : * In this issue, _POSIX_SAVED_IDS is mandated, thus the effective : user ID and effective group ID of the new process image shall be : saved (as the saved set-user-ID and the saved set-group-ID) for : use by the setuid() function. Why you call it "broken"? > > ... > > > > Under OpenBSD, the attached program succeeds: > > None was attached :-). > Sorry, attached now. > > seteuid() to the fake (12345) UID > > setuid() to the real (1010) UID > > seteuid() back to the saved (0) UID > > > > Under FreeBSD, it fails with: > > > > seteuid() to the fake (12345) UID > > setuid() to the real (1001) UID > > seteuid() back to the saved (0) UID > > setuid: seteuid: Operation not permitted > > I think I now understand the purpose of seteuid() before seteuid(). > It is to set the euid to a value such that the process has "appropriate > privilege" for setuid() to set all the ids. "Appropriate privilege" > is implementation-defined and context-dependent. > In Unixware, this means "the calling process has the P_SETUID privilege". > FreeBSD defines it such that everyone has it for the context of setuid() > to their real uid, so setuid(getuid()) always works "right". > I don't have pre-2000 POSIX.1 specs, but POSIX-200x reads: : If the process has appropriate privileges, setuid() shall set the real : user ID, effective user ID, and the saved set-user-ID of the calling : process to uid. : : If the process does not have appropriate privileges, but uid is equal : to the real user ID or the saved set-user-ID, setuid() shall set the : effective user ID to uid; the real user ID and saved set-user-ID shall : remain unchanged. So, from the POSIX.1-200x point of view, FreeBSD currently defines "appropriate privilege" as "if the specified ID is equal to the real user ID or the effective user ID of the process, or if the effective user ID is that of the super user", while OpenBSD extracts from this list "if the specified ID is equal to the real user ID". In any case, the "euid root" is considered "appropriate privilege", and behavior of both FreeBSD and OpenBSD is the same in this case, i.e., set all three IDs (real, effective, and saved) to the specified value. The only case where the seteuid() call would be required before setuid() would be: 1) FreeBSD doesn't consider "the specified ID is equal to the real user ID" the "appropriate privilege" - and - 2) the process in question doesn't have "appropriate privilege", IOW, it's *NOT* set-uid root, which is not the case here, obviously. > IIRC, this > is mainly so that setuid(getuid()) can work at all (when ruid != euid) in > the !_POSIX_SAVE_IDS case. > Hmm, don't the setuid(ruid) was always allowed? > When it works, it works "right" -- it must > set the euid, and it should set any (non-POSIX) saved ids so that it > works the same as on systems without any saved ids. I think this is > all POSIX.1-199[0-6] conformant. BSD4.4-style saved ids can be viewed > as things that control "appropriate privilege". > It's hard to say without having an old, 1003.1-199x text :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="setuid.c" #include <err.h> #include <unistd.h> #include <sys/types.h> int main(void) { uid_t ruid, suid; ruid = getuid(); suid = geteuid(); printf("seteuid() to the fake (%d) UID\n", 12345); if (seteuid((uid_t)12345) == -1) err(1, "seteuid"); printf("setuid() to the real (%d) UID\n", ruid); if (setuid(ruid) == -1) err(1, "setuid"); printf("seteuid() back to the saved (%d) UID\n", suid); if (seteuid(suid) == -1) err(1, "seteuid"); return 0; } --fUYQa+Pmc3FrFX/N-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010510124529.C19855>