On 04/12/12 17:35, Josh Nielsen wrote:
Hi Paul,
Thanks for replying. Interestingly I've never dealt with filesystem ACLs before and I didn't even know that ext3/4 systems had that feature.
Here is my output from those commands:
bash> getfacl tmp8iEccn # file: tmp8iEccn # owner: galaxy # group: galaxy user::rwx group::--- mask::rwx other::---
So, the galaxy group really doesn't have access. If I interpret this correctly, and although the mask is set to not filter anything - it's expressed like the symbolic form of the umask shell built-in (umask -S) and describes permissions, not restrictions - it isn't going to change the capabilities of the galaxy group. Moreover, the mask isn't a default mask which I think is the feature that most directly corresponds to umask. See the following for the complicated details: http://users.suse.com/~agruen/acl/linux-acls/online/
bash> getfacl tmp # file: tmp # owner: root # group: galaxy user::rwx group::rwx other::rwx
What enforces these ACLs/where can they be tweaked?
You can use the setfacl command to change them. However, I don't see anything here that is causing the problem.
P.S. The reason I run Galaxy with sudo is because if I try to do so as just the Galaxy user it cannot create the process lock files: "touch: cannot touch `/var/lock/subsys/galaxy`". I suppose I could put the lock files somewhere else or manually give galaxy group permission to /var/lock/subsys (not so sure that's a good idea though), but sudo seemed to solve the problem. You can see my init script in my reply to Nate.
I think there might be a misunderstanding here. You will need to use sudo to start the service because the lock file will need writing, as you point out, but then the service runs as the galaxy user (as seen in the init script). However, in the previous message, it looked like you had added the galaxy user to the "sudoers" file, which would only be necessary if that user itself needed to elevate its privileges, which I don't think would be necessary under any circumstances (but then I'm a Galaxy beginner, so I can't really say that for sure). I actually think Nate's response is promising here: you need to override the conservative permissions on temporary files after their creation. Alternatively, it might be possible to grant the Apache user access to files in the temporary directory hierarchy, but that might need some experimentation, and I'm not even sure that this wouldn't involve some modifications to the code making the temporary files in the first place. Paul