0

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
  • 1
    sudo -s starts a new shell. It will temporarily suspend the execution of the ~/.bashrc file until that shell exits. I would avoid using sudo at all in a user's shell startup files. Also, you don't execute anything as dummy after having done sudo su, you execute them as root. – Kusalananda Jan 13 at 16:39
  • @Kusalananda Thank you for your explanation, does that mean it is not possible to run a command as a different user while being logged in as root? – a.t. Jan 13 at 16:51
  • It's possible to do that, no problem, but you are showing a .bashrc file that belongs to an ordinary user and it starts a root shell with sudo -s. This shell will just open an interactive prompt and wait for input from whoever is at the terminal. It will not continue running the .bashrc file. – Kusalananda Jan 13 at 16:56
  • I think I do not understand you correctly, because after sudo -s the rest of the .bashrc is automatically executed without me doing anything. I added the output of the .bashrc to show it. – a.t. Jan 13 at 17:07
  • 1
    Sure. See how many times cron was started (the first part of the output)? The .bashrc file is re-running when the shell that sudo -s executes starts. sudo -s starts a new shell, it does not change the user identity in the current shell. Cron starts three times, probably since the permission on /home/dummy/maintenance does not allow dummy to create a file in it. Therefore, sudo -s is run twice. You now have three nested shell sessions. – Kusalananda Jan 13 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.