Related
Besides the question in the title I would like to explain my motivation, maybe there is another solution for my situation.
I work at different stations of a little local network, I usually work in station 3, where I listen to music while I work and where I add new songs to my playlists.
If, for a couple of days, I have to work at station 5, I would like to listen to music saved at one of my playlists. In order to do so, I have to save the playlist to a file in station 3, and then import it in station 5, but sometimes I forget to do it and when I'm already in station 5 I have to go back to station 3 and save the pl.
So, one part is the question asked in the title, and another would be how to automatically update or import the saved playlist (in station 5, or any other.)
Thanks.
Ok, here it goes how I solved my issue. First I have to explain how my network is set:
5 computers in the network, Station 1 is the "File server" giving this service via NFS (all computers in the network are Linux). Stations 2 to 5 mount directories as set in the "/etc/fstab" file, for exemple:
# File server
fileserv:/home/REMOTEUSER/Documents /home/LOCALUSER/Documents nfs4 rsize=8192,wsize=8192,timeo=14,intr,_netdev 0 0
fileserv:/home/REMOTEUSER/Music /home/LOCALUSER/Music nfs4 rsize=8192,wsize=8192,timeo=14,intr,_netdev 0 0
fileserv:/home/REMOTEUSER/Video /home/LOCALUSER/Video nfs4 rsize=8192,wsize=8192,timeo=14,intr,_netdev 0 0
fileserv:/home/REMOTEUSER/Downloads /home/LOCALUSER/Downloads nfs4 rsize=8192,wsize=8192,timeo=14,intr,_netdev 0 0
fileserv:/home/REMOTEUSER/Images /home/LOCALUSER/Images nfs4 rsize=8192,wsize=8192,timeo=14,intr,_netdev 0 0
NOTE: if you don't have your server in the /etc/hosts file you can use the ip instead, like:
192.168.1.1:/home/REMOTEUSER/Documents /home/LOCALUSER/Documents nfs4 rsize=8192,wsize=8192,timeo=14,intr,_netdev 0 0
etc...
Having previous data in mind. In station 3 I have set an every hour cron job that runs the next command (I could find the way to execute a script on logout, but I usually only turnoff the machine which does not run the script. If I put the script in rc6.d the problem is that station 3 root user is not allowed in station 1 (file server), and the "local user" of station 3 is already logged out).
crontab -l
# m h dom mon dow command
0 * * * * cp /home/USER/.local/share/rhythmbox/playlists.xml /home/USER/Documents/USER/musiclists/
To recover music lists from station 3, I have created next script in station 5:
File: .RhythmboxPlaylists.sh
#!/bin/sh
### Modify variables as needed
REMUS="USER" #Remote user
LOCUS="USER" #Local user
### Rhythmbox play list location saved from station 3
ORIGPL="/home/$LOCUS/Documents/$LOCUS/musiclists/playlists.xml"
#### Local Rhythmbox play list location
DESTPL="/home/$LOCUS/.local/share/rhythmbox/playlists.xml"
### DO NOT MODIFY FROM THIS LINE DOWN
sed -i "s/home\/$REMUS\//home\/$LOCUS\//g" $ORIGPL
mv $ORIGPL $DESTPL
Set file as executable
chmod +X .RhythmboxPlaylists.sh
Add next line:
sh $HOME/.RhythmboxPlaylists.sh
at the end of file .bashrc to run it at user login (save .bashrc).
Then, when I open Rhythmbox in station 5 I have the same playlists with the same songs as in station 3.
I finally came out with a partial solution. It is partial because it covers only the "Automatically saving Rhythmbox playlists to files". I still don't know how to automatically load playlists from files into Rhythmbox... let's see the script I've created (which you can put either at starting or shutting down your system):
File: playlist.sh
#!/bin/sh
#Variables [Replace USER by your Linux user and set the playlistDir where suits you the best]
playlistXml="/home/USER/.local/share/rhythmbox/playlists.xml"
playlistDir="/home/USER/musiclists"
# Create a file per list
xmlstarlet sel -t -v 'rhythmdb-playlists/playlist/#name' -nl "$playlistXml" |
while read name; do
xmlstarlet sel -t --var name="'$name'" -v 'rhythmdb-playlists/playlist[#name = $name]' "$playlistXml" > "$playlistDir/$name.pls"
#Delete empty lines from generated files
sed -i "/^$/d" "$playlistDir/$name.pls"
#Add line numbers to define file number
cat -n "$playlistDir/$name.pls" > tmp
mv tmp "$playlistDir/$name.pls"
#Add file headder
songs=$(wc -l < "$playlistDir/$name.pls")
sed -i "1i \[playlist\]\nX-GNOME-Title=$name\nNumberOfEntries=$songs" "$playlistDir/$name.pls"
done
#Format playlist
sed -i -r "s/^\s+([0-9]+)\s+file:(.*)$/File\1=file:\2\nTitle\1=/g" $playlistDir/*.pls
Set the file as executable: chmod +x playlist.sh
I have implemented another user based solution. For this to work you need to log into the different workstations with the same user....
Close Rhythmbox on the stations/users involved.
In the user directory located on the file server create a new subdirectory, let's call it rhythmbox.
Inside the newly created rhythmbox subdirectory, create two new subdirectories, cache and share.
From the workstation where you usually manage Rhythmbox, that is, where you create and maintain playlists, move the Rhythmbox cache to the file server cache directory:
# mv $HOME/.cache/rhythmbox //file-server/home/USER/rhythmbox/cache/
Move the Rhythmbox shared directory to the file server:
# mv $HOME/.local/share/rhythmbox //file-server/home/USER/rhythmbox/share/
Where the original directories where, create symbolic links.
a1. # cd $HOME/.cache/
a2. # ln -s //file-server/home/USER/rhythmbox/cache/rhythmbox
b1. # cd $HOME/.local/share/
b2. # ln -s //file-server/home/USER/rhythmbox/rhythmbox/share/rhythmbox
On the other stations remove the Rhythmbox cache and share directories and replace them with the symbolic links.
Then, the next time you open your Rhythmbox from any station logging in with the same user, your Music application will access the same data, so the settings and playlists will be the same on all stations.
When I use any command with sudo the environment variables are not there. For example after setting HTTP_PROXY the command wget works fine without sudo. However if I type sudo wget it says it can't bypass the proxy setting.
First you need to export HTTP_PROXY. Second, you need to read man sudo, and look at the -E flag. This works:
$ export HTTP_PROXY=foof
$ sudo -E bash -c 'echo $HTTP_PROXY'
Here is the quote from the man page:
-E, --preserve-env
Indicates to the security policy that the user wishes to preserve their
existing environment variables. The security policy may return an error
if the user does not have permission to preserve the environment.
The trick is to add environment variables to sudoers file via sudo visudo command and add these lines:
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"
taken from ArchLinux wiki.
For Ubuntu 14, you need to specify in separate lines as it returns the errors for multi-variable lines:
Defaults env_keep += "http_proxy"
Defaults env_keep += "https_proxy"
Defaults env_keep += "HTTP_PROXY"
Defaults env_keep += "HTTPS_PROXY"
For individual variables you want to make available on a one off basis you can make it part of the command.
sudo http_proxy=$http_proxy wget "http://stackoverflow.com"
You can also combine the two env_keep statements in Ahmed Aswani's answer into a single statement like this:
Defaults env_keep += "http_proxy https_proxy"
You should also consider specifying env_keep for only a single command like this:
Defaults!/bin/[your_command] env_keep += "http_proxy https_proxy"
A simple wrapper function (or in-line for loop)
I came up with a unique solution because:
sudo -E "$#" was leaking variables that was causing problems for my command
sudo VAR1="$VAR1" ... VAR42="$VAR42" "$#" was long and ugly in my case
demo.sh
#!/bin/bash
function sudo_exports(){
eval sudo $(for x in $_EXPORTS; do printf '%q=%q ' "$x" "${!x}"; done;) "$#"
}
# create a test script to call as sudo
echo 'echo Forty-Two is $VAR42' > sudo_test.sh
chmod +x sudo_test.sh
export VAR42="The Answer to the Ultimate Question of Life, The Universe, and Everything."
export _EXPORTS="_EXPORTS VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9 VAR10 VAR11 VAR12 VAR13 VAR14 VAR15 VAR16 VAR17 VAR18 VAR19 VAR20 VAR21 VAR22 VAR23 VAR24 VAR25 VAR26 VAR27 VAR28 VAR29 VAR30 VAR31 VAR32 VAR33 VAR34 VAR35 VAR36 VAR37 VAR38 VAR39 VAR40 VAR41 VAR42"
# clean function style
sudo_exports ./sudo_test.sh
# or just use the content of the function
eval sudo $(for x in $_EXPORTS; do printf '%q=%q ' "$x" "${!x}"; done;) ./sudo_test.sh
Result
$ ./demo.sh
Forty-Two is The Answer to the Ultimate Question of Life, The Universe, and Everything.
Forty-Two is The Answer to the Ultimate Question of Life, The Universe, and Everything.
How?
This is made possible by a feature of the bash builtin printf. The %q produces a shell quoted string. Unlike the parameter expansion in bash 4.4, this works in bash versions < 4.0
Add code snippets to /etc/sudoers.d
Don't know if this is available in all distros, but in Debian-based distros, there is a line at or near the tail of the /etc/sudoers file that includes the folder /etc/sudoers.d. Herein, one may add code "snippets" that modify sudo's configuration. Specifically, they allow control over all environment variables used in sudo.
As with /etc/sudoers, these "code snippets" should be edited using visudo. You can start by reading the README file, which is also a handy place for keeping any notes you care to make:
$ sudo visudo -f /etc/sudoers.d/README
# files for your snippets may be created/edited like so:
$ sudo visudo -f /etc/sudoers.d/20_mysnippets
Read the "Command Environment" section of 'man 5 sudoers'
Perhaps the most informative documentation on environment configuration in sudo is found in the Command environment section of man 5 sudoers. Here, we learn that a sudoers environment variables that are blocked by default may be "whitelisted" using the env_check or env_keep options; e.g.
Defaults env_keep += "http_proxy HTTP_PROXY"
Defaults env_keep += "https_proxy HTTPS_PROXY"
Defaults env_keep += "ftp_proxy FTP_PROXY"
And so, in the OP's case, we may "pass" the sudoer's environment variables as follows:
$ sudo visudo -f /etc/sudoers.d/10_myenvwlist
# opens the default editor for entry of the following lines:
Defaults env_keep += "http_proxy HTTP_PROXY"
Defaults env_keep += "https_proxy HTTPS_PROXY"
# and any others deemed useful/necessary
# Save the file, close the editor, and you are done!
Get your bearings from '# sudo -V'
The OP presumably discovered the missing environment variable in sudo by trial-and-error. However, it is possible to be proactive: A listing of all environment variables, and their allowed or denied status is available (and unique to each host) from the root prompt as follows:
# sudo -V
...
Environment variables to check for safety:
...
Environment variables to remove:
...
Environment variables to preserve:
...
Note that once an environment variable is "whitelisted" as above, it will appear in subsequent listings of sudo -V under the "preserve" listing.
If you have the need to keep the environment variables in a script you can put your command in a here document like this. Especially if you have lots of variables to set things look tidy this way.
# prepare a script e.g. for running maven
runmaven=/tmp/runmaven$$
# create the script with a here document
cat << EOF > $runmaven
#!/bin/bash
# run the maven clean with environment variables set
export ANT_HOME=/usr/share/ant
export MAKEFLAGS=-j4
mvn clean install
EOF
# make the script executable
chmod +x $runmaven
# run it
sudo $runmaven
# remove it or comment out to keep
rm $runmaven
I am new to Fabric 2.0 and recently installed all samples and I was able to run test-network without an issue with 2 orgs. Then I followed the directory on addOrg3 to add 3rd organization and join the channel I created earlier.
Now the fun part came in when I wanted to add 4th organization. What I did was, I copied the addOrg3 folder and renamed almost everything in each file to represent 4th organization. I even assigned new PORT for this organization. However I am seeing the following error.
I've also added the following in Scripts/envVar.sh
export PEER0_ORG4_CA=${PWD}/organizations/peerOrganizations/org4.example.com/peers/peer0.org4.example.com/tls/ca.crt
And added the following in envVarCLI.sh
elif [ $ORG -eq 4 ]; then
CORE_PEER_LOCALMSPID="Org4MSP"
CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG4_CA
CORE_PEER_ADDRESS=peer0.org4.example.com:12051
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/organizations/peerOrganizations/org4.example.com/users/Admin#.../msp
I have also added step1Org4.sh and step2Org4.sh basically following by following addOrg3's structure.
What steps do you follow to add additional organizations ? Please help.
"No such container: Org4cli"
Sorry for the formatting since I wasn't able to put in to coding style but here is the output from running the command "./addOrg4.sh up"
**Add Org4 to channel 'mychannel' with '10' seconds and CLI delay of '3' seconds and using database 'leveldb'
Desktop/blockchain/BSI/fabric-samples/test-network/addOrg4/../../bin/cryptogen
##########################################################
##### Generate certificates using cryptogen tool #########
##########################################################
##########################################################
############ Create Org4 Identities ######################
##########################################################
+ cryptogen generate --config=org4-crypto.yaml --output=../organizations
org4.example.com
+ res=0
+ set +x
Generate CCP files for Org4
Desktop/blockchain/BSI/fabric-samples/test-network/addOrg4/../../bin/configtxgen
##########################################################
####### Generating Org4 organization definition #########
##########################################################
+ configtxgen -printOrg Org4MSP
2020-05-29 13:33:04.609 EDT [common.tools.configtxgen] main -> INFO 001 Loading configuration
2020-05-29 13:33:04.617 EDT [common.tools.configtxgen.localconfig] LoadTopLevel -> INFO 002 Loaded configuration: /Desktop/blockchain/BSI/fabric-samples/test-network/addOrg4/configtx.yaml
+ res=0
+ set +x
###############################################################
####### Generate and submit config tx to add Org4 #############
###############################################################
Error: No such container: Org4cli
ERROR !!!! Unable to create config tx **
In your addOrg4.sh have condition check like this:
CONTAINER_IDS=$(docker ps -a | awk '($2 ~ /fabric-tools/) {print $1}')
if [ -z "$CONTAINER_IDS" -o "$CONTAINER_IDS" == " " ]; then
echo "Bringing up network"
Org4Up
fi
If you already run addOrg3.sh up, CONTAINER_IDS alway have value (Example: 51b4ad60d812). It is ContainerID of Org3cli. So function Org4Up will never call. Simple way is just comment code like this:
# CONTAINER_IDS=$(docker ps -a | awk '($2 ~ /fabric-tools/) {print $1}')
# if [ -z "$CONTAINER_IDS" -o "$CONTAINER_IDS" == " " ]; then
echo "Bringing up network"
Org4Up
# fi
It will bring up Org4cli you missing.
First check the container is up or not and if it is up then I think the CLI where the command is executed is not bootstrapped with the Org4 details.
I have added the 4th Organization from the three Org Hyperledger Fabric Network .Firstly, you have to create the Org4-artifacts (Crypto.yaml and Org4 docker file including the Org4Cli) and then try to follow the manual (step by step) process to add the new Organization from the official documentation.
https://hyperledger-fabric.readthedocs.io/en/release-2.0/channel_update_tutorial.html
Omit the process of editing scripts (step1 Org3.sh ...) because the workflow for adding the 4th or a new Org is slightly changed.So,you will spend a lot of time in just modifying the scripts.
I will write an article to add a new Org (4th) on medium,will paste the link here too.
I have saved some ENV's in ~/.bashrc, I close and reopened the file and they are there for sure.
.bashrc:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
. /etc/apache2/envvars
# If not running interactively, don't do anything else
[ -z "$PS1" ] && return
# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
. /etc/bash_completion
fi
PS1='\[\033[01;32m\]${C9_USER}\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$(__git_ps1 " (%s)") $ '
# If this is an xterm set the title to user#host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u#\h: \w\a\]$PS1"
;;
*)
;;
esac
export rvm_silence_path_mismatch_check_flag=1
export TWILIO_SID="AXXXXX81b7eb5aXXXXeXXX6c9bfecX6X"
export TWILIO_TOKEN="XXX87XXXXXXe650ff2XXXXfXXXXX8X2"
export TWILIO_PHONE_NUMBER="+147043XXXX"
Yet when I tell my rails app to use them, for example use ENV["TWILIO_SID"] in my controller, it does not know them. I tried echoing them out in bash, it's just an empty line, in HTML, also empty line.
I am using c9 cloud IDE, and there is an option to manually enter ENV into the Rails shell, and when I do that, everything works fine. but my assignment asks for bashrc file... why are neither bash nor rails terminal reading my .bashrc? any help?
PS: the overall goal is to just set a UNIX env variable in my Rails app. I cannot use figaro.
PS2: Here is the code in controller where I'm using the variables. When I hard code them, everything works fine, so I know there is something going on with the env variables.
require 'twilio-ruby'
def index
end
class TexterController < ApplicationController
def index
end
def text
#number = params[:number]
#message = params[:message]
twilio_sid = ENV["TWILIO_SID"]
twilio_token = ENV["TWILIO_TOKEN"]
twilio_phone_number = ENV["TWILIO_PHONE_NUMBER"]
#client = Twilio::REST::Client.new(twilio_sid, twilio_token)
#message = #client.messages.create(
to: #number,
from: twilio_phone_number,
body: #message
)
render "pages/text.html.erb"
end
end
And here is the reasons why:
To change the environmental variable "permanently" you'll need to consider at least these situations:
Login/Non-login shell
Interactive/Non-interactive shell
Bash as login shell will load /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile in the order
Bash as non-login interactive shell will load ~/.bashrc
Bash as non-login non-interactive shell will load the configuration specified in environment variable $BASH_ENV
Source: how to permanently set environmental variables
Found it.
Turns out for some reason, even when I source .bashrc, the env variables are not read, but when I added them to .profile they are read and everything works fine.
Even tried adding them to .bashrc and then source ~/.bashrc to .profile, but still wouldn't work.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
This is the PATH variable without sudo:
$ echo 'echo $PATH' | sh
/opt/local/ruby/bin:/usr/bin:/bin
This is the PATH variable with sudo:
$ echo 'echo $PATH' | sudo sh
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
As far as I can tell, sudo is supposed to leave PATH untouched. What's going on? How do I change this? (This is on Ubuntu 8.04).
UPDATE: as far as I can see, none of the scripts started as root change PATH in any way.
From man sudo:
To prevent command spoofing, sudo
checks ``.'' and ``'' (both denoting
current directory) last when searching
for a command in the user's PATH (if
one or both are in the PATH). Note,
however, that the actual PATH
environment variable is not modified
and is passed unchanged to the program
that sudo executes.
This is an annoying function a feature of sudo on many distributions.
To work around this "problem" on ubuntu I do
the following in my ~/.bashrc
alias sudo='sudo env PATH=$PATH'
Note the above will work for commands that don't reset the $PATH themselves.
However `su' resets it's $PATH so you must use -p to tell it not to. I.E.:
sudo su -p
In case someone else runs accross this and wants to just disable all path variable changing for all users.
Access your sudoers file by using the command:visudo. You should see the following line somewhere:
Defaults env_reset
which you should add the following on the next line
Defaults !secure_path
secure_path is enabled by default. This option specifies what to make $PATH when sudoing. The exclamation mark disables the feature.
PATH is an environment variable, and as such is by default reset by sudo.
You need special permissions to be permitted to do this.
From man sudo
-E The -E (preserve environment) option will override the env_reset
option in sudoers(5)). It is only available when either the match-
ing command has the SETENV tag or the setenv option is set in sudo-
ers(5).
Environment variables to be set for the command may also be passed on
the command line in the form of VAR=value, e.g.
LD_LIBRARY_PATH=/usr/local/pkg/lib. Variables passed on the command
line are subject to the same restrictions as normal environment vari-
ables with one important exception. If the setenv option is set in
sudoers, the command to be run has the SETENV tag set or the command
matched is ALL, the user may set variables that would overwise be for-
bidden. See sudoers(5) for more information.
An Example of usage:
cat >> test.sh
env | grep "MYEXAMPLE" ;
^D
sh test.sh
MYEXAMPLE=1 sh test.sh
# MYEXAMPLE=1
MYEXAMPLE=1 sudo sh test.sh
MYEXAMPLE=1 sudo MYEXAMPLE=2 sh test.sh
# MYEXAMPLE=2
update
man 5 sudoers :
env_reset If set, sudo will reset the environment to only contain
the LOGNAME, SHELL, USER, USERNAME and the SUDO_* vari-
ables. Any variables in the caller's environment that
match the env_keep and env_check lists are then added.
The default contents of the env_keep and env_check
lists are displayed when sudo is run by root with the
-V option. If sudo was compiled with the SECURE_PATH
option, its value will be used for the PATH environment
variable. This flag is on by default.
So may need to check that this is/is not compiled in.
It is by default in Gentoo
# ( From the build Script )
....
ROOTPATH=$(cleanpath /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin${ROOTPATH:+:${ROOTPATH}})
....
econf --with-secure-path="${ROOTPATH}"
Looks like this bug has been around for quite a while! Here are some bug references you may find helpful (and may want to subscribe to / vote up, hint, hint...):
Debian bug #85123 ("sudo: SECURE_PATH still can't be overridden") (from 2001!)
It seems that Bug#20996 is still present in this version of sudo. The
changelog says that it can be overridden at runtime but I haven't yet
discovered how.
They mention putting something like this in your sudoers file:
Defaults secure_path="/bin:/usr/bin:/usr/local/bin"
but when I do that in Ubuntu 8.10 at least, it gives me this error:
visudo: unknown defaults entry `secure_path' referenced near line 10
Ubuntu bug #50797 ("sudo built with --with-secure-path is problematic")
Worse still, as far as I can tell, it
is impossible to respecify secure_path
in the sudoers file. So if, for
example, you want to offer your users
easy access to something under /opt,
you must recompile sudo.
Yes. There needs to be a way to
override this "feature" without having
to recompile. Nothing worse then
security bigots telling you what's
best for your environment and then not
giving you a way to turn it off.
This is really annoying. It might be
wise to keep current behavior by
default for security reasons, but
there should be a way of overriding it
other than recompiling from source
code! Many people ARE in need of PATH
inheritance. I wonder why no
maintainers look into it, which seems
easy to come up with an acceptable
solution.
I worked around it like this:
mv /usr/bin/sudo /usr/bin/sudo.orig
then create a file /usr/bin/sudo containing the following:
#!/bin/bash
/usr/bin/sudo.orig env PATH=$PATH "$#"
then your regular sudo works just like the non secure-path sudo
Ubuntu bug #192651 ("sudo path is always reset")
Given that a duplicate of this bug was
originally filed in July 2006, I'm not
clear how long an ineffectual env_keep
has been in operation. Whatever the
merits of forcing users to employ
tricks such as that listed above,
surely the man pages for sudo and
sudoers should reflect the fact that
options to modify the PATH are
effectively redundant.
Modifying documentation to reflect
actual execution is non destabilising
and very helpful.
Ubuntu bug #226595 ("impossible to retain/specify PATH")
I need to be able to run sudo with
additional non-std binary folders in
the PATH. Having already added my
requirements to /etc/environment I was
surprised when I got errors about
missing commands when running them
under sudo.....
I tried the following to fix this
without sucess:
Using the "sudo -E" option - did not work. My existing PATH was still reset by sudo
Changing "Defaults env_reset" to "Defaults !env_reset" in /etc/sudoers -- also did not work (even when combined with sudo -E)
Uncommenting env_reset (e.g. "#Defaults env_reset") in /etc/sudoers -- also did not work.
Adding 'Defaults env_keep += "PATH"' to /etc/sudoers -- also did not work.
Clearly - despite the man
documentation - sudo is completely
hardcoded regarding PATH and does not
allow any flexibility regarding
retaining the users PATH. Very
annoying as I can't run non-default
software under root permissions using
sudo.
This seemed to work for me
sudo -i
which takes on the non-sudo PATH
I think it is in fact desirable to have sudo reset the PATH: otherwise an attacker having compromised your user account could put backdoored versions of all kinds of tools on your users' PATH, and they would be executed when using sudo.
(of course having sudo reset the PATH is not a complete solution to these kinds of problems, but it helps)
This is indeed what happens when you use
Defaults env_reset
in /etc/sudoers without using exempt_group or env_keep.
This is also convenient because you can add directories that are only useful for root (such as /sbin and /usr/sbin) to the sudo path without adding them to your users' paths. To specify the path to be used by sudo:
Defaults secure_path="/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin"
Works now using sudo from the karmic repositories. Details from my configuration:
root#sphinx:~# cat /etc/sudoers | grep -v -e '^$' -e '^#'
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/grub-1.96/sbin:/opt/grub-1.96/bin"
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
root#sphinx:~# cat /etc/apt/sources.list
deb http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe
deb http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe
deb http://security.ubuntu.com/ubuntu jaunty-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu jaunty-security main restricted universe
deb http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe
deb http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe
deb http://security.ubuntu.com/ubuntu karmic-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu karmic-security main restricted universe
root#sphinx:~#
root#sphinx:~# cat /etc/apt/preferences
Package: sudo
Pin: release a=karmic-security
Pin-Priority: 990
Package: sudo
Pin: release a=karmic-updates
Pin-Priority: 960
Package: sudo
Pin: release a=karmic
Pin-Priority: 930
Package: *
Pin: release a=jaunty-security
Pin-Priority: 900
Package: *
Pin: release a=jaunty-updates
Pin-Priority: 700
Package: *
Pin: release a=jaunty
Pin-Priority: 500
Package: *
Pin: release a=karmic-security
Pin-Priority: 450
Package: *
Pin: release a=karmic-updates
Pin-Priority: 250
Package: *
Pin: release a=karmic
Pin-Priority: 50
root#sphinx:~# apt-cache policy sudo
sudo:
Installed: 1.7.0-1ubuntu2
Candidate: 1.7.0-1ubuntu2
Package pin: 1.7.0-1ubuntu2
Version table:
*** 1.7.0-1ubuntu2 930
50 http://au.archive.ubuntu.com karmic/main Packages
100 /var/lib/dpkg/status
1.6.9p17-1ubuntu3 930
500 http://au.archive.ubuntu.com jaunty/main Packages
root#sphinx:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin
root#sphinx:~# exit
exit
abolte#sphinx:~$ echo $PATH
/home/abolte/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/chromium-17593:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/xpra-0.0.6/bin
abolte#sphinx:~$
It's wonderful to finally have this solved without using a hack.
# cat .bash_profile | grep PATH
PATH=$HOME/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
export PATH
# cat /etc/sudoers | grep Defaults
Defaults requiretty
Defaults env_reset
Defaults env_keep = "SOME_PARAM1 SOME_PARAM2 ... PATH"
Just comment out "Defaults env_reset" in /etc/sudoers
Just edit env_keep in /etc/sudoers
It looks something like this:
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE"
Just append PATH at the end, so after the change it would look like this:
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE PATH"
Close the terminal and then open again.
Secure_path is your friend, but if you want to exempt yourself from secure_path just do
sudo visudo
And append
Defaults exempt_group=your_goup
If you want to exempt a bunch of users create a group, add all the users to it, and use that as your exempt_group. man 5 sudoers for more.
the recommended solution in the comments on the OpenSUSE distro suggests to change:
Defaults env_reset
to:
Defaults !env_reset
and then presumably to comment out the following line which isn't needed:
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE"
comment out both "Default env_reset" and "Default secure_path ..." in /etc/sudores file works for me
You can also move your file in a sudoers used directory :
sudo mv $HOME/bash/script.sh /usr/sbin/
Er, it's not really a test if you don't add something to your path:
bill#bill-desktop:~$ ls -l /opt/pkg/bin
total 12
-rwxr-xr-x 1 root root 28 2009-01-22 18:58 foo
bill#bill-desktop:~$ which foo
/opt/pkg/bin/foo
bill#bill-desktop:~$ sudo su
root#bill-desktop:/home/bill# which foo
root#bill-desktop:/home/bill#
The PATH will be reset when using su or sudo by the definition of ENV_SUPATH, and ENV_PATH defined in /etc/login.defs
$PATH is an environment variable and it means that value of $PATH can differ for another users.
When you are doing login into your system then your profile setting decide the value of the $PATH.
Now, lets take a look:-
User | Value of $PATH
--------------------------
root /var/www
user1 /var/www/user1
user2 /var/www/html/private
Suppose that these are the values of $PATH for different user. Now when you are executing any command with sudo then in actual meaning root user executes that command .
You can confirm by executing these commands on terminal :-
user#localhost$ whoami
username
user#localhost$ sudo whoami
root
user#localhost$
This is the reason. I think its clear to you.
It may be counter-intuitive but the first time it happened to me, I knew what was going on. Believe me, you don't want root running someone else's PATH
"Hey root? Can you help me, something is wrong" and he comes over and sudo's from my shell and I wrote a "${HOME}/bin/ls" shell script that first gives me superuser privileges, and then calls the real /bin/ls.
# personal ls
usermod -a -G sudo ${USER}
/bin/ls
The minute root user does "sudo ls" from my shell, he's done and the box is wide open to me.