I'm using AIX 5.3 with sudo 1.6.9p23. Sudoers file grants user fcomartin permission to run any command as user oas:
fcomarti ALL=(oas) ALL
User oas has a bash script called menu, from which it launches another scripts depending on the selected option. The problem is that some of the secondary scripts redirects standard output to text file "temp" which is owned by oas user, when this happens the system tells me that user do not have the right permissions to write.
User fcomarti uses ksh, then the used command is as follows:
sudo -u oas bash menu
(bash because user oas uses bash) Menu starts, menu launches monitorAv script, inside monitorAv is the line echo > temp, it then tells user fcomarti it do not have the right permissions to write.
The script is running as user oas, not as user fcomarti, so if it is trying to write to a file in a directory owned by fcomarti it is probably not going to have the appropriate permissions.
You could make user oas share a group with user fcomarti and then grant group write permissions on certain directories, or you can have the script output to a location that is writeable by the oas user (e.g., /tmp, or some directory you have explicitly created for that purpose, such as the HOME directory for user oas).
I've finally solved the problem, the sintaxis of sudo is as follows:
sudo -u oas bash -c "cd /Oas/bin; menu"
This is because some of the secondary scripts launched by menu, needs an absolute route to work.
Related
When I use command sudo vipw to edit my password file, It's always use vi as editor. I don't like this very much and want to change it to vim.
I already tried:
Add export EDITOR=/usr/local/bin/vim in /etc/profile.
But shell told me "export: Command not found". I thought the reason is export is built-in function only in bash. And I don't want to change my shell.
AddEDITOR=/usr/lcoal/bin/vim in default block of /etc/login.conf
Add setenv EDITOR vim in /root/.cshrc, /.cshrc, ~/.cshrc
All above didn't work at all.
I have google for hours but could not find anything help.
Your /etc/sudoers file doesn't keep your EDITOR environment variable.
I personally have an /etc/sudoers.d/local file, something like
# We don't need to worry about wheel users breaking in to get root access because they already have it.
Defaults:%wheel env_keep+="HOME EDITOR",!set_home,shell_noargs
I'm not sure why this isn't the default, since wheel users have already been given full access. But it's apparently prevailing wisdom to continue hassling them.
Note: If you're using an older /etc/sudoers file that doesn't support an /etc/sudoers.d directory, these lines can be dropped in there... or you could add #includedir /etc/sudoers.d as the last line of your /etc/sudoers file to enable an /etc/sudoers.d directory. Um, yes, the # is a required part of that line, because someone thought it was important for that directive to look like a comment.
Try adding this to the root user /root/.chsrc:
setenv EDITOR vim
or to set it globally to all users using shell tcsh/csh add it in /etc/csh.cshrc
From the man:
A login shell begins by executing commands from the system files /etc/csh.cshrc
and /etc/csh.login. It then executes commands from files in the user's home directory:
first ~/.tcshrc or, if ~/.tcshrc is not found, ~/.cshrc ...
Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on startup.
Also verify vim is installed since is not by default, you could try:
pkg install vim-console
setting the EDITOR or VISUAL environment variable is the key.
if you don't want to go to the trouble of modifying config files (which is indeed the long term solution) then you could sudo su - to get to the root prompt and then you could export EDITOR=/usr/bin/vim before running vipw
There is an empty file called .selected_editor in $HOME (/root).
Remove it and the next call to vipw will ask you to select the editor.
I'm trying to change the $PATH of an individual user in fish-shell so that berryconda runs before default python.
I've found my way to the config.fish file and added what the file says to add for login shells.
if status --is-login
set PATH /root/berryconda3/bin/python $PATH
end
My issue is this doesn't seem to change the $PATH at all and I also only want it to occur for one specific user anyway so I don't think this is correct. How can I go about changing the $PATH of an individual user in fish-shell.
Add the following to the user's ~/.config/fish/config.fish file:
contains /root/berryconda3/bin/python $PATH
or set -gx PATH /root/berryconda3/bin/python $PATH
Using if status is-login to guard the modification is reasonable if you only want it to be done for the first shell launched by a terminal. However, it may never be true if the terminal is configured to launch the shell without marking it a login shell.
Also, that point points to a file in the root acount home dir. That may not be accessible by a non-root user and in any case it is bad idea to have non-root accounts depending on files in the root user home dir.
I want to automate the entire installation of Jenkins, given a list of user names I want to be able to create user accounts for each. The only method I've read to set up user accounts is here:
https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup
Tried seeing if there was an option to configure with command line at:
https://localhost:8080/cli/
But does not seem to the be case.
Is it possible to add user accounts without using the web interface? More specifically a method that is scriptable.
My last resort is to do raw post requests but hoping there is a nicer way.
Yes of course, it is possible to script provisioning for jenkins. But not with the cli tool alone.
I guess you want to use "Jenkins own user database" with Project Matrix Authorization Strategy.
Steps to prepare provisioning:
Configure your Jenkins manually (enable security, add rolls and at least one user)
Shutdown your jenkins (to let him write all in-memory changes to disk)
Copy $JENKINS_HOME/config.xml to your provisioning script (as as seed data)
Copy $JENKINS_HOME/users/ (as seed data)
Get the cli tool: cd /tmp; wget -nv http://localhost:8080/jnlpJars/jenkins-cli.jar
If you do not want to have static seed data (one config.xml for each user) you can generate a (users/username/)config.xml using a bash script or a more advanced tool. But for simplicity sake you can take users/username1/config.xml as a template. Replace relevant data with a placeholder e.g. "PLACEHOLDER_FULLNAME" for full user name.
e.g.:
change
"<fullName>sample full username</fullName>"
to
"<fullName>PLACEHOLDER_FULLNAME</fullName>"
In your provisioning script, iterate over all users. For each user, replace each placeholder with the correct value.
e.g.
cp $SEED_DATA/templates/user/config.xml /tmp/config.xml
sed -e "s/\${PLACEHOLDER_USERNAME}/1/" -e "s/\${ChuckNorris}/dog/" /tmp/config.xml
sed -e "s/\${PLACEHOLDER_EMAIL}/1/" -e "s/\${he#findsyou.com}/dog/" /tmp/config.xml
...
mkdir -p $SEED_DATA/users/$USERNAME/
cp /tmp/config.xml $SEED_DATA/users/$USERNAME/config.xml
When you want to use generated users config.xml please generate for each user some permission settings in $JENKINS_HOME/config.xml:
<authorizationStrategy class="hudson.security.ProjectMatrixAuthorizationStrategy">
...
<permission>hudson.model.View.Create:username1</permission>
<permission>hudson.model.View.Delete:username1</permission>
<permission>hudson.model.View.Read:username1</permission>
...
<permission>hudson.model.View.Create:username2</permission>
<permission>hudson.model.View.Delete:username2</permission>
<permission>hudson.model.View.Read:username2</permission>
...
</authorizationStrategy>
Provisioning steps:
Install jenkins as you did before & maybe dynamic config generator (see above)
cp $SEED_DATA/config.xml $JENKINS_HOME/
cp -R $SEED_DATA/users/ $JENKINS_HOME/
chown -R "jenkins:jenkins" $JENKINS_HOME/users/ (maybe optional)
cd /tmp; java -jar jenkins-cli.jar -s http://localhost:8080/ reload-configuration
System("ls")
System("pwd")
Both these commands just work fine in both production & development mode on the same server.
However System("mkdir test") or any other command that involves creating a new file/dir does not go through in production mode, but works just fine in development mode. Any ideas here?
My guess is it has something to do with permissions but not sure where.
On your server you should have a user different from root for security reasons. Than this user should be added to sudoers list:
https://askubuntu.com/questions/7477/how-can-i-add-a-new-user-as-sudoer-using-the-command-line
now, depending where you want to create this folder, if it's in your app folder where your user has permissions to read/write, (search chmod 755 and chown to set the owner of the folder, better use chown -R to apply this to all subfolders), after this you'll be able to create that folder with:
System("mkdir test")
but only in folders where your user has access to read/write.
If you want to create the test folder in some other path where you need to use sudo you'll have to run:
System("sudo mkdir test")
normally this is running in a background and you won't be there to write the password, so you'll have to add your command to not require password while running sudo, with NOPASSWD directive you can do that:
https://askubuntu.com/questions/159007/how-do-i-run-specific-sudo-commands-without-a-password
sudo visudo -f /etc/sudoers #!important visudo, read in the upper link more about it before trying this.
after doing all this you'll be able to create a folder in your path using:
System("sudo mkdir test")
without requiring a password.
I am trying to execute a command like this from a Ruby on Rails app:
sudo service squid3 restart
If i try it with this code:
output = ´sudo service squid3 retsart´
It don't work, in the console i see that linux asks the password.
How can i pass a password with this command? Or other suggestions...
You can add the following line to your sudoers file (/etc/sudoers)
rails_user ALL=(root) NOPASSWD:/usr/sbin/service
This will basically let the rails_user user execute the service command as sudo, and the system won't ask you for a password.
rails_user should be replaced with whatever user that you are running your rails process under. And you should also make sure that
Defaults requiretty
is not present in your /etc/sudoers. If not you won't be able use sudo from a script.
You can try the sudo -S flag if available on you system (check man):
echo secretPasswd | sudo -S service squid3 restart
This means that the password will be in clear so you can add the user which needs to perform the task to the sudoers (which creates another security issue by the way).
Does your sudo have a -A switch?
-A
Normally, if sudo requires a password, it will read it from the current terminal. If the -A (askpass) option is specified, a helper program is executed to read the user's password and output the password to the standard output. If the SUDO_ASKPASS environment variable is set, it specifies the path to the helper program. Otherwise, the value specified by the askpass option in sudoers(5) is used.
I wouldn't recommend having the password available in any way to your web server processes though so you'd want to use the sudoers file.
You can use the expect method to catch the password prompt and send the password. However, it might be a better idea to allow your Rails user access to the service command without a password using the NOPASSWD option in /etc/sudoers.