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

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:


bash>  getfacl tmp
# file: tmp
# owner: root
# group: galaxy

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.

Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:


Reply via email to