I'm writing a deployment script and have run in to a strange problem...
ian#baster:~$ sudo echo "Build: "$REVISION" - Deployed: "$(date +%Y-%m-%d) > /home/www/prod/www/revision.html
-bash: /home/www/prod/www/revision.html: Permission denied
but...
root#baster:~# echo "Build: "$REVISION" - Deployed: "$(date +%Y-%m-%d) > /home/www/prod/www/revision.html
root#baster:~# more /home/www/prod/www/revision.html
Build: - Deployed: 2011-01-28
then...
ian#baster:~$ sudo ls -l /home/www/prod/www
total 28
-rw-r--r-- 1 root root 31 2011-01-28 21:56 revision.html
ian#baster:~$ sudo more /home/www/prod/www/revision.html
Build: - Deployed: 2011-01-28
What's the deal?
The usual way to do that is with tee:
echo "foo" | sudo tee filename
You can suppress the output to the screen which tee does like this:
echo "foo" | sudo tee filename >/dev/null
The echo is run as root, but not the redirection. Run the redirection in a sudo subshell.
Related
From a main bash script run as root, I want to execute a subprocess using sudo as unpriviledge user nobody; that subprocess should source a file, which content is provided by the main script.
I am trying to solve this using bash process substitution. But I cannot manage to get this to work.
Can someone tell me why the following script, ...
#! /bin/bash
sudo -u nobody \
bash -c 'source /dev/stdin || ls -l /dev/stdin /proc/self/fd/0 /proc/$$/fd/0; echo "A=$A"' \
< <(echo "A=$(ls /root/.profile)")
... when run as root, produces the following ouput ?
root#raspi:~# ./test3.sh
bash: line 1: /dev/stdin: Permission denied
lrwxrwxrwx 1 root root 15 Mar 20 20:55 /dev/stdin -> /proc/self/fd/0
lr-x------ 1 nobody nogroup 64 Aug 21 14:38 /proc/3243/fd/0 -> 'pipe:[79069]'
lr-x------ 1 nobody nogroup 64 Aug 21 14:38 /proc/self/fd/0 -> 'pipe:[79069]'
A=
I would expect reading from stdin to work because, as indicated by ls -l, read access to stdin is granted to nobody (which makes sense).
So why this does not work ? And is there any way to get this to work ?
Answers to this question did not help: as sample above shows, code in the <(...) bloc should access data that only root can.
To see why you have Permission denied, use ls -lL
sudo -u nobody \
bash -c 'source /dev/stdin || ls -lL /dev/stdin /proc/self/fd/0 /proc/$$/fd/0; echo "A=$A"' \
< <(echo "A=$(ls /root/.profile)")
To get around the error, use cat |
sudo -u nobody \
bash -c 'cat | { source /dev/stdin || ls -lL /dev/stdin /proc/self/fd/0 /proc/$$/fd/0; echo "A=$A"; }' \
< <(echo "A=$(ls /root/.profile)")
When I'm executing the bash script it said permission denied on a line. below the script and other details.
#!/bin/bash
find /var/opt/gitlab/backups/ -amin +60 |grep tar | cut -d '/' -f 6 >
/tmp/delete-files.txt
chmod +rw /var/opt/gitlab/backups/*.tar
chmod +rw /tmp/delete-files.txt
for i in `/tmp/delete-files.txt`
do
rm -rf /var/opt/gitlab/backups/$i
[root#git opt]# ./asaaa
./asaaa: line 10: /tmp/delete-files.txt: Permission denied'
[root#git opt]#
[root#git opt]# ll /tmp/delete-files.txt
-rw-r--r--. 1 root root 100 Mar 11 12:43 /tmp/delete-files.txt
[root#git opt]#
Help me to sort out this issue.
This line is incorrect:
for i in `/tmp/delete-files.txt`
Backticks mean command substitution. Your script will try to execute /tmp/delete-files.txt. This is not an executable file.
My guess is that what you wanted to do was:
for i in `cat /tmp/delete-files.txt`
Ie. execute cat command to print the contents of the /tmp/delete-files.txt and then loop through each of the printed lines in the for loop.
Using GitLab-CI, I am attempting to echo a secret variable into a file inside a Docker container. The file exists and the user has permissions to write to the file yet I get a No such file or directory error.
$ /usr/bin/docker exec -t $CI_PROJECT_NAME ls -la /opt/application/conf/kubeadminaccount.yml
-rw-rw-r-- 1 nodeuser nodeuser 420 Aug 18 07:19 /opt/application/conf/kubeadminaccount.yml
$ /usr/bin/docker exec -t $CI_PROJECT_NAME whoami
nodeuser
$ /usr/bin/docker exec -t $CI_PROJECT_NAME echo $KUBE_ADMIN_ACCOUNT > /opt/application/conf/kubeadminaccount.yml
bash: line 69: /opt/application/conf/kubeadminaccount.yml: No such file or directory
Your redirection operator is working on host and not inside your container. Change below
$ /usr/bin/docker exec -t $CI_PROJECT_NAME echo $KUBE_ADMIN_ACCOUNT > /opt/application/conf/kubeadminaccount.yml
to
$ /usr/bin/docker exec -t $CI_PROJECT_NAME bash -c "echo $KUBE_ADMIN_ACCOUNT > /opt/application/conf/kubeadminaccount.yml"
OS: Ubunutu 14.04
In the /home/ubuntu directory, I created the following script:
echo >000-default.conf.test
sudo cp 000-default.conf.test /etc/apache2/sites-enabled/000-default.conf.test
sudo echo 'this is a test'>> /etc/apache2/sites-enabled/000-default.conf.test
sudo cat /etc/apache2/sites-enabled/000-default.conf.test
When I run the script, I get the following error message:
./test_f.sh: line 3: /etc/apache2/sites-enabled/000-default.conf.test: Permission denied
Any ideas why I am getting the error message when the copy operation is succeeding?
Sure.
Redirecting output into files is done by the shell, not by sudo. So if the shell is running under unprivileged user, then >> is invoked earlier than privileges are acquired by sudo.
You can use the following approach:
echo >000-default.conf.test
sudo cp 000-default.conf.test /etc/apache2/sites-enabled/000-default.conf.test
echo 'this is a test' | sudo tee -a /etc/apache2/sites-enabled/000-default.conf.test >/dev/null
sudo cat /etc/apache2/sites-enabled/000-default.conf.test
By the way, instead of
echo >000-default.conf.test
you can use
touch 000-default.conf.test
or even
>000-default.conf.test
This question already has answers here:
Bash Deployment Script Permission Problem
(2 answers)
Closed 8 years ago.
I came across this weird problem just now and I can't seem to get to the bottom of it. I'm trying to add a config file to /etc/sudoers.d/ but get permission denied. In the example below, the file "tweedle" doesn't exist and:
drwxr-xr-x 2 root root 4.0K Jan 2 18:27 sudoers.d/
So here's the command:
$ sudo echo "tweedle ALL=(ALL) ALL" > /etc/sudoers.d/tweedle
-bash: /etc/sudoers.d/tweedle: Permission denied
It doesn't even work when I break it into two commands:
$ sudo touch /etc/sudoers.d/tweedle
$ sudo echo "poodle" > /etc/sudoers.d/tweedle
When I tested it locally, same problem:
$ cd ~
$ mkdir -m 755 tweedle
$ sudo chown root:root tweedle
$ sudo echo "battle" > ~/tweedle/beetle
-bash: /home/spanky/tweedle/beetle: Permission denied
$ sudo touch tweedle/beetle
$ sudo echo "battle" > tweedle/beetle
-bash: tweedle/beetle: Permission denied
Without sudo, all is well:
$ cd ~
$ mkdir poodle
$ echo "noodle" > poodle/bottle
$ cat poodle/bottle
noodle
Thoughts?
The echo command is being run as root, but the redirection is done by your shell, so it's executed as the current user, not as root.
The simplest solution is to invoke a root shell to run both the command and the redirection.
Rather than:
sudo echo line > file
try this:
sudo sh -c 'echo line > file'
or
sudo bash -c 'echo line > file'
The answer is to use "tee" with a pipe, a command I wasn't familiar with, so you can use sudo for the second half:
$ echo "tweedle ALL=(ALL) ALL" | sudo tee /etc/sudoers.d/tweedle