Karel, thank you for considering to add an option to whitelist certain environment variables. I bet my feedback my have given some inspiration 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: […] > > 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 reason. Initializing SSH_AUTH_SOCK manually in a script that runs as root seems much more error prone to me. I chose to have exactly the SSH_AUTH_SOCK of the user who did sudo in the root environment and not the SSH_AUTH_SOCK of another user. It may be better to use sudo anyway, but I am not going to lock my root account on my laptop like its done with Ubuntu by default. I even switched sudo to require the root password on my laptop meanwhile. As sudo can do all this, I don´t really need su, but I think it would not hurt to add an option like it and recommend it over just using su without "-". > > $ su -c 'env VAR="val" myscript' user > > > > Well, this might become slightly trickier with real shell or > > environment> > > variables wrt/ correct shell quoting: > > $ VAR='some value' > > $ su -c 'env VAR="'"$VAR"'" myscript' user > > Well, probably usable way for scripts, but ugly for users on command > line. > > All the idea behind the patch is make things more user-friendly > > su -w GREP_COLOR,COLORFGBG - kzak > > seems better than assume -c 'env VAR ..." I quite like this approach after I got why just taking over the complete environment of the user can cause security and other issues in script behavior at least on machines used by mutiple users. And can cause issues if someone else manages to manipulate the environment of a user only I should have access to. Thanks, -- Martin
