Sample Header Ad - 728x90

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