Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] Silence compilation warnings about setuid, setgid
- X-seq: zsh-workers 43004
- From: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: [PATCH] Silence compilation warnings about setuid, setgid
- Date: Wed, 13 Jun 2018 18:19:21 +0100
- Cms-type: 201P
- Dkim-filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20180613171926euoutp0126c48df7051d2412435cdeceedeaef88~3x_DHrbUx2832928329euoutp01M
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1528910366; bh=1sZM2RLH1V7gTyQoKryAHEavh9FbC3bzgMbf+qdzTuc=; h=Date:From:To:Subject:In-Reply-To:References:From; b=EfbR/WED7abibuokIFBJBtZ8VqKUvKmd4AnYiapG4df3kHQs1MEXJUm3Pm0knQUYw ZSJEmTIkUgQFkLbKBuwm7APogevoCJARCDguT8Q27ulLaKjLTnMj8FjHZiijtIFwZE iBE4KMgix8vFkqvmCYruV6R3YSdqnylJgNdTZcSo=
- In-reply-to: <CAF6rxg=Y1BSfoQLMgyLj4ahJcRp36AN8n2=hwFgxqQ4h0VkAYw@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- Organization: SCSC
- References: <CAKc7PVBWHsOhpC7mZcL4DA0ih=3yJF-HYe+We=r0q1oXA_s38g@mail.gmail.com> <CGME20180613115039epcas5p3f7e70bdce12919686a5dec9895782138@epcas5p3.samsung.com> <CAF6rxgmVA5KtcRoaVZi5P=6OtQdLPzHJowbBm+eyp0Zjea19Sg@mail.gmail.com> <20180613131021eucas1p263704fa9832375e6a49cf7f2077606dc~3ukj6hhqT1702017020eucas1p2W@eucas1p2.samsung.com> <CAH+w=7Z5hNeLpoUkGDMnuk3PRF3BX7+z=EdHQHTVtj1pgasrAA@mail.gmail.com> <CAF6rxg=Y1BSfoQLMgyLj4ahJcRp36AN8n2=hwFgxqQ4h0VkAYw@mail.gmail.com>
On Wed, 13 Jun 2018 10:13:53 -0700
Eitan Adler <lists@xxxxxxxxxxxxxx> wrote:
> On 13 June 2018 at 08:08, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
> wrote:
> > This may have been isolated to a 1990s-era OS that is no longer at
> > issue. Either way there's no particular reason to save and report
> > errno from the first call.
>
> See
> https://wiki.sei.cmu.edu/confluence/display/c/POS37-C.+Ensure+that+privilege+relinquishment+is+successful
> I'm not sure what current systems have these issues, but explicitly
> checking the results of getuid after priv-drop is still considered a
> "good idea"
There's no question of not testing the final result, the question is
whether we need the result of the first one that might erroneously
report success. I've now get this.
pws
diff --git a/Src/options.c b/Src/options.c
index 590652e..a6e3216 100644
--- a/Src/options.c
+++ b/Src/options.c
@@ -769,15 +769,25 @@ dosetopt(int optno, int value, int force, char *new_opts)
} else if(optno == PRIVILEGED && !value) {
/* unsetting PRIVILEGED causes the shell to make itself unprivileged */
#ifdef HAVE_SETUID
- setuid(getuid());
- setgid(getgid());
- if (setuid(getuid())) {
- zwarn("failed to change user ID: %e", errno);
- return -1;
- } else if (setgid(getgid())) {
+ errno = 0;
+ /*
+ * Set the GID first as if we set the UID to non-privileged it
+ * might be impossible to restore the GID.
+ *
+ * Some OSes (possibly no longer around) have been known to
+ * fail silently the first time, so we attempt the change twice.
+ * If it fails we are guaranteed to pick this up the second
+ * time, so ignore the first time.
+ */
+ (void)setgid(getgid());
+ (void)setuid(getuid());
+ if (setgid(getgid())) {
zwarn("failed to change group ID: %e", errno);
return -1;
- }
+ } else if (setuid(getuid())) {
+ zwarn("failed to change user ID: %e", errno);
+ return -1;
+ }
#else
zwarn("setuid not available");
return -1;
Messages sorted by:
Reverse Date,
Date,
Thread,
Author