Permissions

[Dutchsea]

Now that I have SC runniing again I like to have a look at the security.
Especially the permissions.

Can someone help me which user(s)/usergroups should have access to which folders and with what type of access (read/write/exec)

I understand that SC (or Apache?) needs R/W access to the media file directories. (also excute access?). But what is the username for the SC user?

My idea is to create a usergroup "tusers" (trusted users) on my QNAP, add the SC user and other trusted users to this group, and after that change permissions to my media folders like below:

chown -R admin:tuser /mediafolder
chmod -R 770 /mediafolder

Does this make sense?

Some for access to the Swisscenter folders. But which folders should be accessible to which users (probably different for day to day use and for updates?)

Thanks.

[avgjoemomma]

I think the biggest thing that will affect the file and directory permissions is the user that you have Apache running as. There are options in Apache to have it run as a different user after starting up as the root user (in QNAP it is the admin user). That should be the user/group that owns permission to the files and directories for SC.

I recommend just going with one user that Apache runs under and owns the files and directories (i.e. /share/Qweb). I'll admit I had to give up the fight for proper Linux security because the QNAP firmware version I have changes the permissions for /share/Qweb and /share/Qmultimedia with every reboot (back to admin). So I ended up running my webserver (lighttpd) as admin:S You might have a newer firmware version that solves this issue though.

[Dutchsea]

Do you know which user is responsible for the updates of SC?
When I used the guest:guest user/group, SC was not properly updated.

But if I use admin:guest I get the error: "root" installs are not supported in the config screen of SC

See also link

Also, to set all media files with a 777 permission seems somewhat unsafe..

[avgjoemomma]

To detail my set up a bit more,

I use lighttpd as my webserver (Apache is too heavy for my old QNAP) and lighttpd is updated much faster in optware so there is no need to wait for a firmware update to fix security issues or other bugs). I run lighttpd as admin:administrators It's not the safest option but I had to give into this due to the chroot jail that QNAP has implemented. I would not suggest going this route if your QNAP can handle Apache well as there are too many workarounds to get things working properly

I'm not sure how QC checks to if it is installed by root. For the initial install I would chown everything by guest:guest ( that is the user Apache should be running as and also the user that would perform the SC update). Permissions should be -rw-rw-r-- )For the media directories, I give Other rwx access to the directories which will allow SC to read the media (/share/Qmultimedia) and also write the image files. The media itself (.avi, etc just needs to be read only for ugo -rw-r--r-- )

[Dutchsea]

OK, I think I get the picture. Most of it is very logical but as I got strange results when trying different permission settings I got confused.

I would not suggest going this route if your QNAP can handle Apache well

No worries, I tried to add lightpd to my Synology in the past => crahed and burned

I'm not sure how QC checks to if it is installed by root.

For some details, see here

I would chown everything by guest:guest ( that is the user Apache should be running as and also the user that would perform the SC update).

SC/Apache user seems to be different in my case. Thats probably why the outcome of my changes to permissions failed. When I look at the files created (xml & jpg) by the mediasearch they are all owned by user httpduser [99]

Can I conclude that this is the SC/Apache user? Also, does it make sense to try change this user?

(FYI, the guest account is disabled for all my folders on the QNAP)

[avgjoemomma]

There you go, try chowning the files by httpduser and hopefully that will do the trick. Now I remember that apache starts up as root but instantly forks to httpduser to perform the actual work for security.