zsh-workers
 help / color / mirror / code / Atom feed
From: dana <dana@dana.is>
To: Zsh hackers list <zsh-workers@zsh.org>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>
Subject: [BUG] Issue with set built-in in 5.8 (?)
Date: Sun, 16 Feb 2020 20:19:07 -0600	[thread overview]
Message-ID: <6908034E-BC9E-41B3-8457-111F275AF3A7@dana.is> (raw)

I think there is arguably a regression in the way the set built-in works in
5.8, or at least a change in behaviour that we might consider further. The
implications hadn't occurred to me until just now, sorry :/

Unlike setopt, when set gets an error back from dosetopt(), it aborts the
shell. Before 5.8, the only errors you were likely to see in the real world
were usage-related ones (e.g., `set -b` or `set -o fakeoption`). It *was*
possible to get an error if setuid() or setgid() failed, but this should be
very rare.

Now, due to the extra error checks we do, it's much more likely that
dosetopt() can return non-zero when unsetting PRIVILEGED: the functions might
not be available, the user might not have permission to do initgroups(), the
sanity checks at the end might find that we're able to restore privileges, &c.

Most of these errors are useful, but i'm not sure they should unconditionally
abort the shell.

Possibilities:

1. We could reconsider which errors should be reported and/or make dosetopt()
   return non-zero. The main one i have doubts about is the initgroups()
   permission one. It is expected that unprivileged users can't update their
   supplementary groups, so warning the user about this condition, let alone
   treating it as an error, may be excessive

2. We could do something like have dosetopt() return <0 for halting errors and
   >0 for ones non-halting, and have bin_set() handle accordingly

3. I'm over-thinking it

@Daniel, we talked about the first one before, but this particular concern
didn't come up at the time — what do you reckon?

dana


% sudo perl -e '$< = 1; $> = 2; exec("zsh", "-fc", "id; unsetopt privileged; echo still here");'
uid=1(daemon) gid=1(daemon) euid=2 egid=0(wheel) groups=...
zsh:unsetopt:1: PRIVILEGED: supplementary group list not changed due to lack of permissions: EUID=2
zsh:unsetopt:1: can't change option: privileged
still here

% sudo perl -e '$< = 1; $> = 2; exec("zsh", "-fc", "id; set +p; echo still here");'
uid=1(daemon) gid=1(daemon) euid=2 egid=0(wheel) groups=...
zsh:unsetopt:1: PRIVILEGED: supplementary group list not changed due to lack of permissions: EUID=2
zsh:set:1: can't change option: -p


             reply	other threads:[~2020-02-17  2:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-17  2:19 dana [this message]
2020-02-17  9:02 ` Daniel Shahaf
2020-02-18 20:01   ` dana
2020-02-19  9:37     ` Peter Stephenson
2020-02-19 19:25       ` dana
2020-02-20  9:30         ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6908034E-BC9E-41B3-8457-111F275AF3A7@dana.is \
    --to=dana@dana.is \
    --cc=d.s@daniel.shahaf.name \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).