How can I persist $SHELLOPTS in sudo - linux

When I sudo to root vi mode is turned off, so that I need to either run set -o vi or change root's profile to use vi mode. I don't want to change the profile as this will impact other engineers and I don't want to have to type set -o vi every time I sudo. I read man sudo and tried sudo -i and sudo -sE, but neither of these preserved $SHELLOPTS where vi mode is set.
I did find that setting env_keep += SHELLOPTS in /etc/sudoers fixed the issue, but this file is being maintained by a config mgmt system and I don't want to make such a global change just because I prefer vi as my command line editor. So, ultimately is there a way I can set this when sudoing that will not require making changes to shared and/or managed config files?
[user#host:~]$ echo $SHELLOPTS
braceexpand:hashall:histexpand:history:interactive-comments:monitor:vi
[user#host:~]$ sudo -i
[root#host:~]# echo $SHELLOPTS
braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
[user#host:~]$ sudo -sE
[root#host:~]# echo $SHELLOPTS
braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor

Related

How can I get a secure system-wide oh-my-zsh configuration?

I'd like to have a system-wide oh-my-zsh setup, but I'm not sure what would be the "best" approach for this. It is not my intention to ask about personal preferences or the like, I'm just unsure whether the solutions below are:
ln my local user configuration somewhere doesn't seem right, because adding an exploit to my local cfg and therefore gain root permissions would be very easy.
Installing oh-my-zsh to /etc would be maybe also a security hole because I simply haven't written it by myself.
Simply writing my own personal .zshrc would be the last approach I would like to try out because it’s very time-consuming.
Any recommendations?
Unless I'm misunderstanding the marked answer from Caleb is just the normal per-user installation steps with adding a .zshrc file to the skel dir and changing the default new-user shell, but it doesn't actually work or really answer the question because each user still requires the oh-my-zsh dir/would still require each user to clone the oh-my-zsh dir into their own folder meaning it's not really installed system wide, it just automatically gives them a zshrc file and changes the default shell to zsh, but without oh-my-zsh in each user folder it will error out.
From what I understand of the question it's asking how to install oh-my-zsh system-wide aka have it installed in ONE place and not require manually messing around on each new user/having a git clone of oh-my-zsh on each user dir. Assuming that's the case, here's what I did based off Arch Linux's AUR Package I normally use but was looking for the same on a centos server, however this can be done on any distro. Credit goes to MarcinWieczorek and the other maintainers, I just adapted the below so can do the same on non-arch distros.
If you already have oh-my-zsh installed on root just skip to Step 3. This isn't distro specific just uses the AUR Patch File for zshrc
Step #1
Install zsh of course
Step #2
Install oh-my-zsh as root as normal (shows wget method, see Calebs answer for alternative)
sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"
Step #3
Move the install to /usr/share so is system-wide
#Copy zsh files to /usr/share for all uer access
mv /root/.oh-my-zsh /usr/share/oh-my-zsh
# Move into the dir and copy the zshrc template to zshrc (which will be the default for users)
cd /usr/share/oh-my-zsh/
cp templates/zshrc.zsh-template zshrc
# Nab the patch file from MarcinWieczorek's AUR Package and apply to the zshrc file
wget https://aur.archlinux.org/cgit/aur.git/plain/0001-zshrc.patch\?h\=oh-my-zsh-git -O zshrc.patch && patch -p1 < zshrc.patch
Now oh-my-zsh is installed globally and the user just needs that zshrc file. so NOW is where Caleb's answer comes in though just do the below as /etc/adduser.conf is only on debian whereas the below should be distro independent.
Step #4
Set it up to be the default on new users
# Create hard link to the zshrc file so it creates an actual independent copy on new users
sudo ln /usr/share/oh-my-zsh/zshrc /etc/skel/.zshrc
# Set default shell to zsh
sudo adduser -D -s /bin/zsh
Now that's a true installation of oh-my-zsh with all new users automatically having it applied with the /usr/share/oh-my-zsh/zshrc settings and no other steps needed.
Misc Notes
For any pre-existing users with oh-my-zsh:
cp /usr/share/oh-my-zsh/zshrc ~/.zshrc
You can set new user OMZ defaults in /usr/share/oh-my-zsh/zshrc
Auto Updates are disabled since new users do not have permissions to update the /usr/share/oh-my-zsh files
To update oh-my-zsh just cd to /usr/share/oh-my-zsh/ and run 'sudo git pull'
The oh-my-zsh cache will be handled per-user within each user dir under ~/.oh-my-zsh-cache/ (automatically created)
Fair Warning: this assumes a Debian style linux, but this should work on other forms as well. This also assumes you are starting from scratch.
Part 1, the install:
You will need to install zsh system wide, and not just for one user. (you may have already done this but I'll include it just to be comprehensive)
make sure you have installed zsh, simply: sudo apt-get install zsh
Follow the oh-my-zsh install guide or you can either:
use curl
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
use wget
sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"
Part 2, Setting up zsh when new users are added:
You will need to make it so that new users default to zsh. In your /etc/adduser.conf file edit the line that says:
DSHELL=/bin/sh
to:
DSHELL=/bin/zsh
You should also change it for the /etc/default/useradd file, change the line:
SHELL=/bin/sh
to:
SHELL=/bin/zsh
Part 3, set your custom theme.
I have a custom theme file (here) that I wanted all users on the system to have. First, you should add the file to your .oh-my-zsh/themes folder:
cp your_custom_style.zsh-theme ~/.oh-my-zsh/themes
Next, edit your .zshrc file in your home directory, change the ZSH_THEME="default" to ZSH_THEME="your_custom_style"
Then, reload your .zshrc file with: . ~/.zshrc
Part 4, setting up new user's home directories.
We need to to place whatever files we want the new users to have in the /etc/skel directory, because this is what the system copies when it is creating new user's home directory. See this sys admin guide for details.
Copy your user's files (you may need to sudo):
cp -r .oh-my-zsh /etc/skel/
cp .zshrc /etc/skel
Now you will be able to add new users and they will have oh-my-zsh by
default with whatever custom theme you want them to have.
If you want to change all other existing user's shell to zsh, I would recommend reading this serverfault question.
If you want a system-wide install of Oh-My-Zsh, a convenient approach that overwrites the least number files is:
sudo git clone https://github.com/robbyrussell/oh-my-zsh.git /etc/oh-my-zsh
sudo cp /etc/oh-my-zsh/templates/zshrc.zsh-template /etc/skel/.zshrc
sudo mkdir -p /etc/skel/.oh-my-zsh/cache
Edit /etc/skel/.zshrc:
Edit the line export ZSH=$HOME/.oh-my-zsh (currently line 5)
Change the line to be:
export ZSH=/etc/oh-my-zsh
export ZSH_CACHE_DIR=~/.oh-my-zsh/cache
Then edit /etc/default/useradd and change the line SHELL=... to SHELL=/bin/zsh.
That's basically all (of course, git and zsh must be installed already).
To update a pre-existing user: login as them and cp /etc/skel/.zshrc ~/.zshrc
Update: Please do not edit this. I just rolled back an edit which completely botched it up!
Login as ROOT
Step 1: Install ZSH
# Download and extract ZSH
wget https://github.com/zsh-users/zsh/archive/zsh-5.8.tar.gz -P /tmp/demo/zsh
cd /tmp/demo/zsh
tar -xvzf zsh-*
cd zsh-zsh-5.8
# configure and make
sudo ./Util/preconfig
sudo ./configure
sudo make && sudo make install
# Add ZSH to the list of shells
echo /usr/local/bin/zsh | sudo tee -a /etc/shells
Step 2: Install oh-my-zsh
# If you're running the Oh My Zsh install script as part of an automated install,
# you can pass the flag --unattended to the install.sh script.
# This will have the effect of not trying to change the default shell, and also won't
# run zsh when the installation has finished.
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended
# Add oh-my-zsh to /usr/share
mv /root/.oh-my-zsh /usr/share
mv /usr/share/.oh-my-zsh /usr/share/oh-my-zsh
mv /root/.zshrc /usr/share/oh-my-zsh
mv /usr/share/oh-my-zsh/.zshrc /usr/share/oh-my-zsh/zshrc
# Modify zshrc to point to /usr/share/oh-my-zsh
sed -i 's|export ZSH="'"$HOME"'/.oh-my-zsh"|export ZSH="\/usr\/share\/oh-my-zsh"|g' /usr/share/oh-my-zsh/zshrc
Step 3: Add Extra (Optional - Look at the bottom for extra features)
Step 4: Create Symbolic link
# Create Symbolic Links to /etc/skel
sudo ln /usr/share/oh-my-zsh/zshrc /etc/skel/.zshrc
Step 5: Add oh-my-zsh for root
# Change shell to ZSH for root
echo "$USER" | chsh -s /usr/local/bin/zsh
Step 6: Add oh-my-zsh for user
# Change user
su - username
# Copy zshrc to $HOME for user
cp /usr/share/oh-my-zsh/zshrc ~/.zshrc
# Change shell to ZSH for user
echo "$USER" | chsh -s /usr/local/bin/zsh
OR
sudo -i -u username bash << EOF
cp /usr/share/oh-my-zsh/zshrc ~/.zshrc
echo username | chsh -s /usr/local/bin/zsh
EOF
EXTRA:
Change theme to powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-/usr/share/oh-my-zsh/custom}/themes/powerlevel10k
sed -i 's/ZSH_THEME="robbyrussell"/ZSH_THEME="powerlevel10k\/powerlevel10k"/g' /usr/share/oh-my-zsh/zshrc
Enable Auto correction
sed -i 's/# ENABLE_CORRECTION="true"/ENABLE_CORRECTION="true"/g' /usr/share/oh-my-zsh/zshrc
Enable Auto suggestions and Syntax highlighting
git clone --depth=1 https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-/usr/share/oh-my-zsh/custom}/plugins/zsh-autosuggestions
git clone --depth=1 https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-/usr/share/oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
sed -i 's/plugins=(git)/plugins=(\n git\n zsh-autosuggestions\n zsh-syntax-highlighting\n)/' /usr/share/oh-my-zsh/zshrc
sed -i 's/plugins=(git)/plugins=(git)\nZSH_DISABLE_COMPFIX=true/' /usr/share/oh-my-zsh/zshrc
Add nord dircolors
git clone --depth=1 https://github.com/arcticicestudio/nord-dircolors.git /tmp/demo/dircolors
mv /tmp/demo/dircolors/src/dir_colors /usr/share/
cd /usr/share/
mv /usr/share/dir_colors /usr/share/.dir_colors
tee -a /usr/share/oh-my-zsh/zshrc >/dev/null <<'EOF'
test -r "/usr/share/.dir_colors" && eval $(dircolors /usr/share/.dir_colors)
EOF
I combined cFINNY's answer, reading and understanding the oh-my-zsh install script, the AUR patch in his answer, and fixing the broken adduser command to do this install in a FROM ubuntu:bionic (Ubuntu 18.04) Dockerfile :
RUN git clone \
-c core.eol=lf \
-c core.autocrlf=false \
-c fsck.zeroPaddedFilemode=ignore \
-c fetch.fsck.zeroPaddedFilemode=ignore \
-c receive.fsck.zeroPaddedFilemode=ignore \
--depth=1 \
--branch master \
https://github.com/ohmyzsh/ohmyzsh.git \
/usr/share/oh-my-zsh \
# Adapt zshrc template
&& cd /usr/share/oh-my-zsh/ \
&& cp templates/zshrc.zsh-template zshrc \
&& sed -i 's/export ZSH=$HOME\/.oh-my-zsh/export ZSH=\/usr\/share\/oh-my-zsh/g' zshrc \
&& sed -i 's/# DISABLE_AUTO_UPDATE="true"/DISABLE_AUTO_UPDATE="true"/g' zshrc \
&& sed -i 's/source $ZSH\/oh-my-zsh.sh//g' zshrc \
&& sed -i 's/ZSH_THEME="robbyrussell"/ZSH_THEME="bira"/g' zshrc \
&& echo '\n \
\n \
ZSH_CACHE_DIR=$HOME/.cache/oh-my-zsh \n \
if [[ ! -d $ZSH_CACHE_DIR ]]; then \n \
mkdir -p $ZSH_CACHE_DIR \n \
fi \n \
\n \
source $ZSH/oh-my-zsh.sh \n \
' >> zshrc \
# Copy zshrc template to $HOME on user creation
&& ln /usr/share/oh-my-zsh/zshrc /etc/skel/.zshrc \
# Setting the default shell for new users has no effect since:
# 1. The default shell is specified when creating new users in entrypoint
# 2. The `ade enter` command will execute `bash` anyways
&& sed -i 's/DSHELL=\/bin\/bash/DSHELL=\/bin\/zsh/g' /etc/adduser.conf
There's also a simple way to do this as well:
Login as the root user and install zsh
sudo su
apt-get install zsh
Then login as another user of the system:
su username
export ZSH=/home/username/.oh-my-zsh
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
Follow same procedures for all users who want oh-my-zsh

Is it possible that when using sudo command it should first source a file?

I need to run a bunch of scripts (with sudo) that use a single file.sh as a configuration file for all. Initially I've put the file.sh in /etc/profile.d and when I ran the scripts as root everything was ok (because when I connected to the machine it first sourced the file.sh and all vars in that file were available) but now, for security reasons, I need to run them with another user with sudo rights.
When running with sudo the "configuration file" in /etc/profile.d does not get sourced even if I'm root and do sudo - it's the same.
Using "sudo -E" is not an option, also this kind of solution "Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"" does not work for me as the vars in the file change a lot and it's easier to throw a file, with all the vars, in a location - like /etc/profile.d/ - instead to adding options to /etc/sudoers.
Later Edit (working):
Moved original sudo command to sudo.orig. Created a new sudo bash script
[root#NS1 bin]# cat sudo
#!/bin/bash
source /etc/profile.d/set_env_vmdeploy.sh
sh /usr/bin/sudo.orig "$#"
and gave it permissions
[root#NS1 bin]# chmod 4111 sudo
[root#NS1 bin]# ll sudo*
---s--x--x 1 root root 78 May 7 13:42 sudo
---s--x--x 1 root root 123832 Jul 31 2014 sudo.orig
If you want sudo to execute all the profile scripts in the child shell, you can tell it to invoke the shell as a login shell: sudo -i /usr/local/bin/my_script.sh. (Note that the child shell will start with the working directory set to /root, and also that this may have other unintended side effects.)
Alternatively, invoke bash explicitly with a command parameter: sudo /bin/bash -c "source ./config.sh; ./real_script.sh".

How to fix 'sudo: no tty present and no askpass program specified' error?

I am trying to compile some sources using a makefile. In the makefile there is a bunch of commands that need to be ran as sudo.
When I compile the sources from a terminal all goes fine and the make is paused the first time a sudo command is ran waiting for password. Once I type in the password, make resumes and completes.
But I would like to be able to compile the sources in NetBeans. So, I started a project and showed netbeans where to find the sources, but when I compile the project it gives the error:
sudo: no tty present and no askpass program specified
The first time it hits a sudo command.
I have looked up the issue on the internet and all the solutions I found point to one thing: disabling the password for this user. Since the user in question here is root. I do not want to do that.
Is there any other solution?
Granting the user to use that command without prompting for password should resolve the problem. First open a shell console and type:
sudo visudo
Then edit that file to add to the very end:
username ALL = NOPASSWD: /fullpath/to/command, /fullpath/to/othercommand
eg
john ALL = NOPASSWD: /sbin/poweroff, /sbin/start, /sbin/stop
will allow user john to sudo poweroff, start and stop without being prompted for password.
Look at the bottom of the screen for the keystrokes you need to use in visudo - this is not vi by the way - and exit without saving at the first sign of any problem. Health warning: corrupting this file will have serious consequences, edit with care!
Try:
Use NOPASSWD line for all commands, I mean:
jenkins ALL=(ALL) NOPASSWD: ALL
Put the line after all other lines in the sudoers file.
That worked for me (Ubuntu 14.04).
Try:
ssh -t remotehost "sudo <cmd>"
This will remove the above errors.
After all alternatives, I found:
sudo -S <cmd>
The -S (stdin) option causes sudo to read the password from the standard input instead of the terminal device.
Source
Above command still needs password to be entered. To remove entering password manually, in cases like jenkins, this command works:
echo <password> | sudo -S <cmd>
sudo by default will read the password from the attached terminal. Your problem is that there is no terminal attached when it is run from the netbeans console. So you have to use an alternative way to enter the password: that is called the askpass program.
The askpass program is not a particular program, but any program that can ask for a password. For example in my system x11-ssh-askpass works fine.
In order to do that you have to specify what program to use, either with the environment variable SUDO_ASKPASS or in the sudo.conf file (see man sudo for details).
You can force sudo to use the askpass program by using the option -A. By default it will use it only if there is not an attached terminal.
Try this one:
echo '' | sudo -S my_command
For Ubuntu 16.04 users
There is a file you have to read with:
cat /etc/sudoers.d/README
Placing a file with mode 0440 in /etc/sudoers.d/myuser with following content:
myuser ALL=(ALL) NOPASSWD: ALL
Should fix the issue.
Do not forget to:
chmod 0440 /etc/sudoers.d/myuser
Login into your linux. Fire following commands. Be careful, as editing sudoer is a risky proposition.
$ sudo visudo
Once vi editor opens make the following changes:
Comment out Defaults requiretty
# Defaults requiretty
Go to the end of the file and add
jenkins ALL=(ALL) NOPASSWD: ALL
If by any chance you came here because you can't sudo inside the Ubuntu that comes with Windows10
Edit the /etc/hosts file from Windows (with Notepad), it'll be located at: %localappdata\lxss\rootfs\etc, add 127.0.0.1 WINDOWS8, this will get rid of the first error that it can't find the host.
To get rid of the no tty present error, always do sudo -S <command>
This worked for me:
echo "myuser ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
where your user is "myuser"
for a Docker image, that would just be:
RUN echo "myuser ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
In Jenkins:
echo '<your-password>' | sudo -S command
Eg:-
echo '******' | sudo -S service nginx restart
You can use Mask Password Plugin to hide your password
Make sure the command you're sudoing is part of your PATH.
If you have a single (or multi, but not ALL) command sudoers entry, you'll get the sudo: no tty present and no askpass program specified when the command is not part of your path (and the full path is not specified).
You can fix it by either adding the command to your PATH or invoking it with an absolute path, i.e.
sudo /usr/sbin/ipset
Instead of
sudo ipset
Command sudo fails as it is trying to prompt on root password and there is no pseudo-tty allocated (as it's part of the script).
You need to either log-in as root to run this command or set-up the following rules in your /etc/sudoers
(or: sudo visudo):
# Members of the admin group may gain root privileges.
%admin ALL=(ALL) NOPASSWD:ALL
Then make sure that your user belongs to admin group (or wheel).
Ideally (safer) it would be to limit root privileges only to specific commands which can be specified as %admin ALL=(ALL) NOPASSWD:/path/to/program
I think I can help someone with my case.
First, I changed the user setting in /etc/sudoers referring to above answer. But It still didn't work.
myuser ALL=(ALL) NOPASSWD: ALL
%mygroup ALL=(ALL:ALL) ALL
In my case, myuser was in the mygroup.
And I didn't need groups. So, deleted that line.
(Shouldn't delete that line like me, just marking the comment.)
myuser ALL=(ALL) NOPASSWD: ALL
It works!
Running shell scripts that have contain sudo commands in them from jenkins might not run as expected. To fix this, follow along
Simple steps:
On ubuntu based systems, run " $ sudo visudo "
this will open /etc/sudoers file.
If your jenkins user is already in that file, then modify to look like this:
jenkins ALL=(ALL) NOPASSWD: ALL
save the file
Relaunch your jenkins job
you shouldnt see that error message again :)
This error may also arise when you are trying to run a terminal command (that requires root password) from some non-shell script, eg sudo ls (in backticks) from a Ruby program. In this case, you can use Expect utility (http://en.wikipedia.org/wiki/Expect) or its alternatives.
For example, in Ruby to execute sudo ls without getting sudo: no tty present and no askpass program specified, you can run this:
require 'ruby_expect'
exp = RubyExpect::Expect.spawn('sudo ls', :debug => true)
exp.procedure do
each do
expect "[sudo] password for _your_username_:" do
send _your_password_
end
end
end
[this uses one of the alternatives to Expect TCL extension: ruby_expect gem].
For the reference, in case someone else encounter the same issue, I was stuck during a good hour with this error which should not happen since I was using the NOPASSWD parameter.
What I did NOT know was that sudo may raise the exact same error message when there is no tty and the command the user try to launch is not part of the allowed command in the /etc/sudoers file.
Here a simplified example of my file content with my issue:
bguser ALL = NOPASSWD: \
command_a arg_a, \
command_b arg_b \
command_c arg_c
When bguser will try to launch "sudo command_b arg_b" without any tty (bguser being used for some daemon), then he will encounter the error "no tty present and no askpass program specified".
Why?
Because a comma is missing at the end of line in the /etc/sudoers file...
(I even wonder if this is an expected behavior and not a bug in sudo since the correct error message for such case shoud be "Sorry, user bguser is not allowed to execute etc.")
I was getting this error because I had limited my user to only a single executable 'systemctl' and had misconfigured the visudo file.
Here's what I had:
jenkins ALL=NOPASSWD: systemctl
However, you need to include the full path to the executable, even if it is on your path by default, for example:
jenkins ALL=NOPASSWD: /bin/systemctl
This allows my jenkins user to restart services but not have full root access
If you add this line to your /etc/sudoers (via visudo) it will fix this problem without having to disable entering your password and when an alias for sudo -S won't work (scripts calling sudo):
Defaults visiblepw
Of course read the manual yourself to understand it, but I think for my use case of running in an LXD container via lxc exec instance -- /bin/bash its pretty safe since it isn't printing the password over a network.
Using pipeline:
echo your_pswd | sudo -S your_cmd
Using here-document:
sudo -S cmd <<eof
pwd
eof
#remember to put the above two lines without "any" indentations.
Open a terminal to ask password (whichever works):
gnome-terminal -e "sudo cmd"
xterm -e "sudo cmd"
I faced this issue when working on an Ubuntu 20.04 server.
I was trying to run a sudo command from a remote machine to deploy an app to the server. However when I run the command I get the error:
sudo: no tty present and no askpass program specified
The remote script failed with exit code 1
Here's how I fixed it:
The issue is caused by executing a sudo command which tries to request for a password, but sudo does not have access to a tty to prompt the user for a passphrase. As it can’t find a tty, sudo falls back to an askpass method but can’t find an askpass command configured, so the sudo command fails.
To fix this you need to be able to run sudo for that specific user with no password requirements. The no password requirements is configured in the /etc/sudoers file. To configure it run either of the commands below:
sudo nano /etc/sudoers
OR
sudo visudo
Note: This opens the /etc/sudoers file using your default editor.
Next, Add the following line at the bottom of the file:
# Allow members to run all commands without a password
my_user ALL=(ALL) NOPASSWD:ALL
Note: Replace my_user with your actual user
If you want the user to run specific commands you can specify them
# Allow members to run specific commands without a password
my_user ALL=(ALL) NOPASSWD:/bin/myCommand
OR
# Allow members to run specific commands without a password
my_user ALL=(ALL) NOPASSWD: /bin/myCommand, /bin/myCommand, /bin/myCommand
Save the changes and exit the file.
For more help, read the resource in this link: sudo: no tty present and no askpass program specified
That's all.
I hope this helps
The solution to the problem is
If you came across this issue anywhere else apart from the Jenkins instance follow this from the 2nd step. The first step is for the user who is having issue with the Jenkins instance.
Go to Jenkins instance of Google Cloud Console.
Enter the commands
sudo su
visudo -f /etc/sudoers
Add following line at the end
jenkins ALL= NOPASSWD: ALL
Checkout here to understand the rootcause of this issue
No one told what could cause this error, in case of migration from one host to another, remember about checking hostname in sudoers file:
So this is my /etc/sudoers config
User_Alias POWERUSER = user_name
Cmnd_Alias SKILL = /root/bin/sudo_auth_wrapper.sh
POWERUSER hostname=(root:root) NOPASSWD: SKILL
if it doesn't match
uname -a
Linux other_hostname 3.10.17 #1 SMP Wed Oct 23 16:28:33 CDT 2013 x86_64 Intel(R) Core(TM) i3-4130T CPU # 2.90GHz GenuineIntel GNU/Linux
it will pop up this error:
no tty present and no askpass program specified
Other options, not based on NOPASSWD:
Start Netbeans with root privilege ((sudo netbeans) or similar) which will presumably fork the build process with root and thus sudo will automatically succeed.
Make the operations you need to do suexec -- make them owned by root, and set mode to 4755. (This will of course let any user on the machine run them.) That way, they don't need sudo at all.
Creating virtual hard disk files with bootsectors shouldn't need sudo at all. Files are just files, and bootsectors are just data. Even the virtual machine shouldn't necessarily need root, unless you do advanced device forwarding.
Although this question is old, it is still relevant for my more or less up-to-date system. After enabling debug mode of sudo (Debug sudo /var/log/sudo_debug all#info in /etc/sudo.conf) I was pointed to /dev: "/dev is world writable". So you might need to check the tty file permissions, especially those of the directory where the tty/pts node resides in.
I was able to get this done but please make sure to follow the steps properly.
This is for the anyone who is getting import errors.
Step1: Check if files and folders have got execute permission issue.
Linux user use:
chmod 777 filename
Step2: Check which user has the permission to execute it.
Step3: open terminal type this command.
sudo visudo
add this lines to the code below
www-data ALL=(ALL) NOPASSWD:ALL
nobody ALL=(ALL) NOPASSWD:/ALL
this is to grant permission to execute the script and allow it to use all the libraries. The user generally is 'nobody' or 'www-data'.
now edit your code as
echo shell_exec('sudo -u the_user_of_the_file python your_file_name.py 2>&1');
go to terminal to check if the process is running
type this there...
ps aux | grep python
this will output all the process running in python.
Add Ons:
use the below code to check the users in your system
cut -d: -f1 /etc/passwd
Thank You!
1 open /etc/sudoers
type sudo vi /etc/sudoers. This will open your file in edit mode.
2 Add/Modify linux user
Look for the entry for Linux user. Modify as below if found or add a new line.
<USERNAME> ALL=(ALL) NOPASSWD: ALL
3 Save and Exit from edit mode
I had the same error message when I was trying to mount sshfs which required sudo : the command is something like this :
sshfs -o sftp_server="/usr/bin/sudo /usr/lib/openssh/sftp-server" user#my.server.tld:/var/www /mnt/sshfs/www
by adding the option -o debug
sshfs -o debug -o sftp_server="/usr/bin/sudo /usr/lib/openssh/sftp-server" user#my.server.tld:/var/www /mnt/sshfs/www
I had the same message of this question :
sudo: no tty present and no askpass program specified
So by reading others answer I became to make a file in /etc/sudoer.d/user on my.server.tld with :
user ALL=NOPASSWD: /usr/lib/openssh/sftp-server
and now I able to mount the drive without giving too much extra right to my user.
Below actions work for on ubuntu20
edit /etc/sudoers
visudo
or
vi /etc/sudoers
add below content
userName ALL=(ALL) NOPASSWD: ALL
%sudo ALL=(ALL:ALL) NOPASSWD:ALL
I'm not sure if this is a more recent change, but I just had this problem and sudo -S worked for me.

Is there a way to set kptr_restrict to 0?

I am currently having trouble running linux perf, mostly because /proc/sys/kernel/kptr_restrict is currently set to 1.
However, if I try to /proc/sys/kernel/kptr_restrict by echoing 0 to it as follows...
echo 0 > /proc/sys/kernel/kptr_restrict
I get a permission denied error. I don't think I can change permissions on it either.
Is there a way to set this directly somehow? I am super user. I don't think perf will function acceptably without this being set.
In your example, echo is running as root, but your shell is running as you.
So please try this command:
sudo sh -c " echo 0 > /proc/sys/kernel/kptr_restrict"
All the files located in /proc/sys can only be modified by root (actually 99.9% files, check with ls -l). Therefore you have to use sudo to modify those files (or your preferred way to execute commands as root).
The proper way to modify the files in /proc/sys is to use the sysctl tool. Note that yu should replace the slashes (/) with dots (.) and omit the /proc/sys/ prefix... read the fine manual.
Read the current value:
$ sysctl kernel.kptr_restrict
kernel.kptr_restrict = 1
Modify the value:
$ sudo sysctl -w kernel.kptr_restrict=0
sysctl kernel.kptr_restrict=1
To make your modifications reboot persistent, you should edit /etc/sysctl.conf or create a file in /etc/sysctl.d/50-mytest.conf (edit the file as root or using sudoedit), containing:
kernel.kptr_restrict=1
In which case you should execute this command to reload your configuration:
$ sysctl -p /etc/sysctl.conf
P.S. it is possible to directly write in the virtual file. https://stackoverflow.com/users/321730/cdyson37 command is quite elegant: echo 0 | sudo tee /proc/sys/kernel/kptr_restrict

Why this linux command can affect the environment variables?

When I changed my current user to admin using
sudo su admin
I found that the environment variable changed too. What I intend to do is to change my user to admin with the env not changed.
Then I found a command as follows:
sudo bash -c "su - admin"
This command does indeed what I want, but I googled about bash -c, with no clue to why this command can do that for me. Could anyone give me a clear explanation? Thanks a lot.
first you should read the sudo manpage and set theses options in the /etc/sudoers file or you can do it interactively (see second below).
default sudoers file may not preserve the existing $USER environment unless you set the config options to do so. You'll want to read up on env_reset because depending on your OS distribution the sudo config will be different in most cases.
I dont mean to be terse but I am on a mobile device..
I do not recommend using sudo su .. for anything. whomever is sharing sudo su with the public is a newb, and you can accomplish the same cleaner with just sudo.
with your example whats happining is you are starting a subshell owned by the original user ("not admin") . you are starting the subshell with -c "string" sudo has the equivelant of the shell's -c using -s which either reads the shell from the arg passed to -s or the shell defined in the passwd file.
second you should use:
$ sudo -u admin -E -s
much cleaner right ? :)
-u sets the user, obviously
-s we just explained
-E preserves the orig user env
see for yourself just
$ echo $HOME # should show the original users /home/orig_user
$ env
your original env is preserved with none of that sudo su ugliness.
if you were interested in simulating a users login without preserving the env..
$ sudo -u user -i
or for root:
Might require -E depending on distro sudoers file
$ sudo -s
or
$ sudo -i
-i simulates the login and uses the users env.
hopefully this helps and someone will kindly format it to be more readable since im on my mobile.
bash with -c argument defines below.
-c string
If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0.
Thanks & Regards,
Alok

Resources