From: Martin Steigerwald <martin@lichtvoll.de>
To: Karel Zak <kzak@redhat.com>
Cc: Bernhard Voelker <mail@bernhard-voelker.de>,
Bruce Dubbs <bruce.dubbs@gmail.com>,
util-linux@vger.kernel.org
Subject: Re: su(1) --whitelist-environment
Date: Tue, 14 Aug 2018 12:47:39 +0200 [thread overview]
Message-ID: <13005040.2n2PM0qaVI@merkaba> (raw)
In-Reply-To: <20180814093257.nglcor4c3jagjyxv@ws.net.home>
Karel, thank you for considering to add an option to whitelist certain=20
environment variables. I bet my feedback my have given some inspiration=20
to this.
Karel Zak - 14.08.18, 11:32:
> On Mon, Aug 13, 2018 at 10:57:01PM +0200, Bernhard Voelker wrote:
> > On 08/10/2018 11:06 PM, Bruce Dubbs wrote:
[=E2=80=A6]
> > I'm 50:50. The point was to pass in variables values per
> > environment
> > to a process inside 'su' (or 'sudo'), and one can achieve that with
> > e.g.
> BTW, sudo has env_check, env_delete, or env_keep to control
> environment in the sudoers.
I meanwhile use sudo for taking over SSH_AUTH_SOCK exactly for this=20
reason. Initializing SSH_AUTH_SOCK manually in a script that runs as=20
root seems much more error prone to me. I chose to have exactly the=20
SSH_AUTH_SOCK of the user who did sudo in the root environment and not=20
the SSH_AUTH_SOCK of another user.
It may be better to use sudo anyway, but I am not going to lock my root=20
account on my laptop like its done with Ubuntu by default. I even=20
switched sudo to require the root password on my laptop meanwhile. As=20
sudo can do all this, I don=C2=B4t really need su, but I think it would not=
=20
hurt to add an option like it and recommend it over just using su=20
without "-".
> > $ su -c 'env VAR=3D"val" myscript' user
> >=20
> > Well, this might become slightly trickier with real shell or
> > environment>=20
> > variables wrt/ correct shell quoting:
> > $ VAR=3D'some value'
> > $ su -c 'env VAR=3D"'"$VAR"'" myscript' user
>=20
> Well, probably usable way for scripts, but ugly for users on command
> line.
>=20
> All the idea behind the patch is make things more user-friendly
>=20
> su -w GREP_COLOR,COLORFGBG - kzak
>=20
> seems better than assume -c 'env VAR ..."
I quite like this approach after I got why just taking over the complete=20
environment of the user can cause security and other issues in script=20
behavior at least on machines used by mutiple users. And can cause=20
issues if someone else manages to manipulate the environment of a user=20
only I should have access to.
Thanks,
=2D-=20
Martin
next prev parent reply other threads:[~2018-08-14 10:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-10 9:24 su(1) --whitelist-environment Karel Zak
2018-08-10 21:06 ` Bruce Dubbs
2018-08-13 20:57 ` Bernhard Voelker
2018-08-14 9:32 ` Karel Zak
2018-08-14 10:47 ` Martin Steigerwald [this message]
2018-08-14 12:50 ` Bernhard Voelker
2018-08-15 11:04 ` Karel Zak
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=13005040.2n2PM0qaVI@merkaba \
--to=martin@lichtvoll.de \
--cc=bruce.dubbs@gmail.com \
--cc=kzak@redhat.com \
--cc=mail@bernhard-voelker.de \
--cc=util-linux@vger.kernel.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.
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).