sabnzbd is mucking with permissions

[jrebeiro]

I have a mount point /usr/local/usenet/ owned by usenet.usenet and chmod'd to 775

Sabnzbd runs as the user usenet in daemon mode and is set to use /usr/local/usenet/sabnzbd/* as it's path

I set the folder permissions in sabnzbd to 0644 since I do not want files downloaded from usenet to be +x

After every single download /usr/local/usenet/* is chmod'd to 764 and I constantly have to reset permissions on that mount point to access the files from my user account.

Also, in the logs I am seeing this:

2009-01-23 00:16:02,344
ERROR
[postproc] Cannot change permissions of /usr/local/usenet/sabnzbd/downloads/complete/blah/blah.ext

I am running Ubuntu 8.10 and sabnzbd 0.4.6 installed via the unofficial debian package via apt-get

[shypike]

Quote from the Wiki http://sabnzbd.wikidot.com/unix-permissions:

In Config->Folders you can specify which access rights SABnzbd should give the end result.
This parameter is passed to the CHMOD command. It uses the octal notation supported by CHMOD.
You need to specify the settings for folders, so with the X bits set, SABnzbd will automatically remove any X bits for the files.
Also note that folders and files will always have private access (SABnzbd does not allow blocking of private access).

[jrebeiro]

So that fixed my problem and helps me understand how sabnzbd uses that setting.. however there still appears to be a bug that sabnzbd will chmod parent folders which it should not be touching.

For example, when set to 644 and setting the download folder to /usr/local/usenet/sabnzbd/downloads/complete

/usr/local/usenet/ has it's permissions reset to 744 which is what it should be setting /usr/local/usenet/sabnzbd/downloads/complete/something to

It also changes /usr/local/usenet/sabnzbd/, /usr/local/usenet/sabnzbd/downloads/, and /usr/local/usenet/sabnzbd/downloads/complete/

This could impact some systems where the user wants the downloads folder to be 775'd but wants parent folders to remail 755'd. Sabnzbd would reset all the permissions it can to 755. I suspect the reason that /usr/ and /usr/local/ don't get changed is that the usenet user has no permissions on those folders.

[shypike]

Yes, this is an implementation problem.
Where do you start in the tree?
Any other way of implementing has it's pros and cons.
The assumption now is that you want the full tree (or at least the
part where SABnzbd is allowed to modify) to have the same permissions.
Giving lower parts of the tree less permissions is often
not feasible.
The assumption is also that those parts of tree where you do not want
permissions to change, SABnzbd will have no permission to do so anyway.

[trmentry]

I believe I'm seeing similar behavior. 

I have sabnzbd running as myself (trmentry).  I have it set up to use /home/trmentry/usenet as it's place for completed files.  It is set for 0755 in the config.

/home/trmentry/.sabnzbd/sabnzbd/  is where temp/incomplete, etc is located. 

I notice that sabnzbd will change /home/trmentry to 755 from 700 when it extracts the files. 

Is this expected behavior?  I'm guessing so if I'm reading this post correctly.

Thanks

[shypike]

Permission changes are to the "complete" path only.
So if /home/trmentry is part of the "complete" path then it will change the permissions.

It doesn't make sense to set /home/trmentry/complete/my-job to 0755, but keep /home/trmentry at 0700.
Nobody will be able to access the complete folder!
So either you allow reading in this home folder or you keep the "complete" path separate from the home folder.

[m00au]

It doesn't make sense for the /home/user to be set at 0700 when /home/user/complete/job to 0755, but it makes perfect sense in some installations to set /home/user to 0755 and /home/user/complete/job to 0775. This is to allow users in the group to delete files in the job directory, but not allow group members to delete critical files in the /home/user/.sabnzbd or /home/user/.ssh directories.
In my opinion, the correct way sabnzbd should handle permission changes is to set the permissions at the tree */complete and under, not changing permissions anywhere higher in the tree.

[m00au]

Here's a patch. This patch will change so that permissions of already existing directories are not modified:

Code: Select all

--- SABnzbd-0.4.6/sabnzbd/misc.py     2008-12-12 09:05:20.000000000 +1100
+++ sabnzbd/sabnzbd/misc.py  2009-02-15 23:23:21.000000000 +1100
@@ -526,12 +526,12 @@
                     try:
                         os.mkdir(path)
                         result = True
+                        try:
+                            if umask: os.chmod(path, int(umask, 8) | 0700)
+                        except:
+                            pass
                     except:
                         result = False
-                try:
-                    if umask: os.chmod(path, int(umask, 8) | 0700)
-                except:
-                    pass
     return result

 ################################################################################

[shypike]

Makes sense.
I'll check for side-effects, but this could be the way to do it.
Thanks for the tip.

It does have one side effect.
Suppose the /blabla/complete folder exists.
SABnzbd will never adjust the settings of this base folder.
Maybe not what people expect?

[m00au]

if /blabla exists, the user must make sure the permissions of that directory is writable by sabnzbd anyway, so that we can actually create /blabla/complete. So if /blabla/complete exists, the user must make sure that /blabla/complete is writable instead of /blabla - it is the same task for the user just at a different tree level.

IMO, the best solution would be setting the umask with os.umask(umask) before the files are being created so that none of this chmodding has to take place.

[shypike]

This would also mean that all SABnzbd "private" files would get other rights.
Very undesirable from a security point of view, especially if you have to run
SABnzbd as root.
Also, unrar may ignore umask (the poster may have used other access rights).

I think your first proposal (don't change rights of existing folders) is best.
Ticket: https://trac2.assembla.com/SABnzbd/ticket/238