3

My sudo file has two commands in it right now that are allowed to run without logging in as root.

It looks like this:

user ALL=(root) NOPASSWD: /home/user/prog1.py
user ALL=(root) NOPASSWD: /home/user/prog2.py

The prog1.py file runs fine without password needed. The prog2.py file fails on permissions denied?

The first program is only accessing a file to read that is root protected. The second program is creating a symlink and removing a root-protected file:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
from random import choice
from subprocess import Popen


def back_drop_change():
    link = "/usr/share/slim/themes/default/background.jpg"
    os.remove(link) # this is the line that returns permission denied
    image_selection = list()
    for di, _, fi in os.walk("/home/user/pictures/apod"):
        for f in fi:
            image_selection.append(di + "/" + f)
    bck_img = choice(image_selection)
    Popen(["ln", "-s", bck_img, link])

if __name__ == "__main__":
    back_drop_change()

I try adding /usr/bin/rm /usr/share/slim/themes/default/background.jpg to the visudo file but, it still fails?

EDIT:

Some extra information -- sudo -l returns:

Matching Defaults entries for user on this host:
    env_reset, editor="/usr/bin/vim -p -X", !env_editor

User user may run the following commands on this host:
    (ALL) ALL
    (root) NOPASSWD: /home/user/Pidtrk/main.py
    (root) NOPASSWD: /home/user/backdrop.py

and again, I am able to run python2 Pidtrk/main.py without errors but, not python2 backdrop.py.

And both these files are owned by the same User and have the same Permissions.

EDIT 2:

I have both of prog1.py and prog2.py running in a crontab on @reboot.

If I have this line in crontab:

`python2 /home/user/prog1.py >> err.log 2>&1`

without:

user ALL=(root) NOPASSWD: /home/user/prog1.py

Inside my sudoers file, the err.log shows it failed with permissions denied.

Now when I add in this line to sudoers:

user ALL=(root) NOPASSWD: /home/user/prog1.py

The prog1.py runs fine on reboot, why is this any different for the prog2.py file?

|improve this question
  • What are the permissions of /home/user/prog2.py? In particular, is it marked executable? – tripleee May 27 '13 at 17:37
  • 2
    You should not need to add rm to sudoers; once you manage to run prog2.py as root, all its child processes will inherit the root permissions (unless you take explicit steps to drop privileges; complex scripts should do this in order to minimize the amount of privileged code). – tripleee May 27 '13 at 17:40
  • Wouldn't it be a lot better to have your X session pick up its background image from an unprivileged location instead? – tripleee May 27 '13 at 17:42
  • Better yet use an app: vajrasky.wordpress.com/wallpapoz – slm♦ May 27 '13 at 17:56
  • To get the permissions of the file, run ls -l /home/user/prog2.py and look at the farthest-left column. Or, post the output of stat -c '%A %a %u' /home/user/prog2.py; id here. – user26112 May 27 '13 at 18:00
2

As indicated in a clarifying comment, you are attempting to run python2 /home/user/backdrop.py. But you have granted yourself permission to run a different command -- viz. /home/user/backdrop.py without the python2 -- which you are not allowed to do. sudo is very particular about what it allows; either run exactly the command you have the permissions for, or change sudoers to allow exactly the command you actually want to run.

|improve this answer
  • Are you sure it succeeds? My speculation is that Pidtrk either fails silently, or works without sudo. But we have yet to see precise, unambiguous examples of what exactly you are doing and how exactly it is failing. – tripleee May 27 '13 at 19:52
  • 1
    Now you are saying python2.7 instead of python2...? – tripleee May 27 '13 at 19:58
1

If you are sure that

  1. the error is caused within the script
  2. the sudo call is correct

then the problem is most probably not sudo. There are several cases in which root is not allowed to remove a file:

  1. The file is on a volume which is mounted read-only (see cat /proc/mounts).
  2. The file is protected by file system attributes (see lsattr "$path").
  3. The parent directory is protected by file system attributes.
  4. Fancy intervening kernel stuff (SELinux, Apparmor).

It may also be helpful to add a few seconds of waiting time in the script and attach with strace to it (as root): strace -f -p $PID

|improve this answer
  • @tijko If the script waits a moment before it tries its operation you can check with ps as which user it is running. – Hauke Laging May 27 '13 at 20:04
  • @tijko So the problem is still with the sudo call and the sudo configuration. I would expect a sudo error message in that case. Make a test script which just waits and check with ps -e -o pid,user,euser,suser,args (to be sure). As tripleee pointed out: It seems that you are inconsistent about your sudoers config and your sudo calls. – Hauke Laging May 27 '13 at 20:28

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.