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
___________________________________________________________
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:
http://lists.bx.psu.edu/
