Raising permissions of account "dummy" when executing command from "root" as "dummy"?
0
votes
0
answers
139
views
**Context:**
While trying to execute command
su a -c task
as user dummy
when being logged (with sudo su
in as root
on Ubuntu 16.04, I receive the following error message:
> root@DESKTOP-344ab:/home/dummy# su dummy -c task
>`[task next] Taskwarrior does not have the correct permissions for
> '/home/dummy/.task/pending.data'. root@DESKTOP-344ab:/home/dummy#`
Whereas when I first switch from root
back to user with su dummy
* and then execute task
it runs fine. *When the dummy
account is logged in, the following .bashrc
file from /home/dummy/.bashrc
is executed automatically before the user can do anything:
sudo -i service cron start
#get root
if [ ! -f /home/a/maintenance/getRootBool ]; then
echo "Getting sudo rights now."
touch /home/a/maintenance/getRootBool
sudo -s
fi
# remove got root boolean for next time you boot up Unix
sudo rm /home/a/maintenance/getRootBool
#Start cron service
#sudo -i service cron start
#Startup taskwarrior
export TASKDDATA=/var/taskd
cd $TASKDDATA
sudo taskd config --data $TASKDDATA
taskdctl start
task sync
Which leads to the following "user description" in the bottom left of terminal: root@DESKTOP-344ab:~#
. That slightly confuses me because it still says root
even though when I cd ~
it goes to /home/dummy
, which seems like it has root
permission but is still in the dummy account
.
So I think the sudo -s
from the .bashrc
script raises the permissions of user dummy
to root.
**Question:** How do I raise the permissions of the dummy
account when executing a command as: su dummy -c task
as user dummy
from root
?
**Attempts:**
1. su dummy -c sudo task
, that indicates the usage of sudo
is not correct, meaning I did not use valid syntax.
2. info sudo
To inspect what the sudo -s
exactly does in the .bashrc
script as that appears to be the permission raising command whilst still staying within the dummy
user. That says:
> -s, --shell
> Run the shell specified by the SHELL environment variable if it is set or the shell specified by the invoking user's
> password database entry. If a command is specified, it
> is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed.
It mainly appears to affect shell commands, currently I am unsure whether task
is a shell command, and if yes, how the sudo -s
raises permission. It makes me doubt my assumption that it probably is the sudo -s
indeed the permission raising command. I am looking further into that.
**Additionally:**
As a response to the comments below, the output of the .bashrc
file is:
* Starting periodic command scheduler cron [ OK ]
Getting sudo rights now.
touch: cannot touch '/home/dummy/maintenance/getRootBool': Permission denied
* Starting periodic command scheduler cron [ OK ]
Getting sudo rights now.
* Starting periodic command scheduler cron [ OK ]
Configuration read from /var/taskd/config
Variable Value
------------- --------------------------
ca.cert /var/taskd/ca.cert.pem
client.cert /var/taskd/client.cert.pem
client.key /var/taskd/client.key.pem
confirmation 1
debug.tls 3
extensions /usr/libexec/taskd
ip.log on
log /var/taskd/taskd.log
pid.file /var/taskd/taskd.pid
queue.size 10
request.limit 1048576
root /var/taskd
server 0.0.0.0:53583
server.cert /var/taskd/server.cert.pem
server.crl /var/taskd/server.crl.pem
server.key /var/taskd/server.key.pem
trust strict
verbose 1
/usr/bin/taskdctl start: daemon started
Syncing with myserver.com:53583
Sync successful. No changes.
root@DESKTOP-344ab:/var/taskd# test
Asked by a.t.
(103 rep)
Jan 13, 2019, 04:14 PM
Last activity: Jan 13, 2019, 05:07 PM
Last activity: Jan 13, 2019, 05:07 PM