Required Galaxy umask settings for HTML downloads?
Hello all, I am having issues downloading HTML files from Galaxy the same as is described in this email chain: http://lists.bx.psu.edu/pipermail/galaxy-dev/2012-August/010965.html I am getting the error "(13)Permission denied: xsendfile: cannot open file: /basedir/galaxy_data/database/tmp/tmp8iEccn/library_download.zip" which is indeed a basic filesystem permissions issue. The problem is that the permissions created for that directory and every directory created in tmp/ look like this: drwx------+ 2 galaxy galaxy 3 Dec 4 09:23 tmp8iEccn And I have placed the Apache user in the galaxy group, but as you can see no group permissions ever get set by Galaxy on the directories that it creates (it is getting a 700 permissions setting). As Nate Coraor suggested in the message linked to above, I have tried altering the default umask but I ran into issues with getting non-existant results. I use "sudo service galaxy start" as the galaxy user each time to start the server and a "ps -ef | grep galaxy" confirms that Galaxy is running as the galaxy user. Since I use sudo though I changed the sudoers file to include: root ALL=(ALL) ALL galaxy ALL=(ALL) ALL Defaults umask_override Defaults umask = 0002 This changed absolutely nothing. Then I started looking deeper into the PAM configuration and added a umask directive to /etc/pam.d/sudo (and also tried it in password-auth-ac and system-auth-ac) like this: "session optional pam_umask.so umask=0002". Still nothing changed in the permissions in tmp/ when I tried to download an HTML file: no group permissions were set. Then I dug deeper still and saw that sometimes if setting the mask in /etc/pam.d/ config files is not enough that you can try to set a system-wide mask in /etc/login.defs (following the suggestion here: http://stackoverflow.com/questions/10220531/how-to-set-system-wide-umask). Still no dice. I've pretty much exhausted my know-how in this department. Any other suggestions of how to fix this or where the correct place to set the umask is? Thanks, Josh Nielsen
On Dec 4, 2012, at 10:52 AM, Josh Nielsen wrote:
Hello all,
I am having issues downloading HTML files from Galaxy the same as is described in this email chain:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2012-August/010965.html
I am getting the error "(13)Permission denied: xsendfile: cannot open file: /basedir/galaxy_data/database/tmp/tmp8iEccn/library_download.zip" which is indeed a basic filesystem permissions issue. The problem is that the permissions created for that directory and every directory created in tmp/ look like this:
drwx------+ 2 galaxy galaxy 3 Dec 4 09:23 tmp8iEccn
And I have placed the Apache user in the galaxy group, but as you can see no group permissions ever get set by Galaxy on the directories that it creates (it is getting a 700 permissions setting).
As Nate Coraor suggested in the message linked to above, I have tried altering the default umask but I ran into issues with getting non-existant results. I use "sudo service galaxy start" as the galaxy user each time to start the server and a "ps -ef | grep galaxy" confirms that Galaxy is running as the galaxy user. Since I use sudo though I changed the sudoers file to include:
root ALL=(ALL) ALL galaxy ALL=(ALL) ALL Defaults umask_override Defaults umask = 0002
This changed absolutely nothing. Then I started looking deeper into the PAM configuration and added a umask directive to /etc/pam.d/sudo (and also tried it in password-auth-ac and system-auth-ac) like this: "session optional pam_umask.so umask=0002". Still nothing changed in the permissions in tmp/ when I tried to download an HTML file: no group permissions were set. Then I dug deeper still and saw that sometimes if setting the mask in /etc/pam.d/ config files is not enough that you can try to set a system-wide mask in /etc/login.defs (following the suggestion here: http://stackoverflow.com/questions/10220531/how-to-set-system-wide-umask). Still no dice. I've pretty much exhausted my know-how in this department. Any other suggestions of how to fix this or where the correct place to set the umask is?
Hi Josh, Thanks for doing such extensive tests. Have you tried setting the umask in the init script itself? --nate
Thanks, Josh Nielsen
Hi Nate, Thanks for the reply. No I hadn't thought to add anything to /etc/init.d/galaxy itself. It is a short enough script that I can paste it below. What would I need to do to edit it with umask settings? Also I should note, changing the umask in the PAM files actually did change the default permissions for the galaxy user when I did an "su - galaxy" in a bash shell and then created or 'touch'-ed any files (which you could logically expect). But for some reason it didn't seem to make a difference with the directories created in that tmp/ directory even though the galaxy user was given ownership. That made me wonder if something was going on internal to Galaxy, or something else, that was overwriting/ignoring the system umask settings (which actually work fine in a shell environment as the user itself). Maybe I'll look into that ACL stuff Paul mentioned. Here is my /etc/init.d/galaxy script: ------------------------ . /etc/rc.d/init.d/functions GALAXY_USER=galaxy GALAXY_DIST_HOME=/home/galaxy/galaxy-dist GALAXY_RUN="${GALAXY_DIST_HOME}/run.sh" GALAXY_PID="${GALAXY_DIST_HOME}/paster.pid" case "$1" in start) echo -n "Starting galaxy services: " daemon --user $GALAXY_USER "${GALAXY_RUN} --daemon --pid-file=${GALAXY_PID}" touch /var/lock/subsys/galaxy ;; stop) echo -n "Shutting down galaxy services: " daemon --user $GALAXY_USER "${GALAXY_RUN} --stop-daemon" rm -f /var/lock/subsys/galaxy ;; status) daemon --user galaxy "${GALAXY_RUN} --status" ;; restart) $0 stop; $0 start ;; reload) $0 stop; $0 start ;; *) echo "Usage: galaxy {start|stop|status|reload|restart}" ;; esac -------------- Thanks! Josh On Tue, Dec 4, 2012 at 9:56 AM, Nate Coraor <nate@bx.psu.edu> wrote:
On Dec 4, 2012, at 10:52 AM, Josh Nielsen wrote:
Hello all,
I am having issues downloading HTML files from Galaxy the same as is described in this email chain:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2012-August/010965.html
I am getting the error "(13)Permission denied: xsendfile: cannot open file: /basedir/galaxy_data/database/tmp/tmp8iEccn/library_download.zip" which is indeed a basic filesystem permissions issue. The problem is that the permissions created for that directory and every directory created in tmp/ look like this:
drwx------+ 2 galaxy galaxy 3 Dec 4 09:23 tmp8iEccn
And I have placed the Apache user in the galaxy group, but as you can see no group permissions ever get set by Galaxy on the directories that it creates (it is getting a 700 permissions setting).
As Nate Coraor suggested in the message linked to above, I have tried altering the default umask but I ran into issues with getting non-existant results. I use "sudo service galaxy start" as the galaxy user each time to start the server and a "ps -ef | grep galaxy" confirms that Galaxy is running as the galaxy user. Since I use sudo though I changed the sudoers file to include:
root ALL=(ALL) ALL galaxy ALL=(ALL) ALL Defaults umask_override Defaults umask = 0002
This changed absolutely nothing. Then I started looking deeper into the PAM configuration and added a umask directive to /etc/pam.d/sudo (and also tried it in password-auth-ac and system-auth-ac) like this: "session optional pam_umask.so umask=0002". Still nothing changed in the permissions in tmp/ when I tried to download an HTML file: no group permissions were set. Then I dug deeper still and saw that sometimes if setting the mask in /etc/pam.d/ config files is not enough that you can try to set a system-wide mask in /etc/login.defs (following the suggestion here: http://stackoverflow.com/questions/10220531/how-to-set-system-wide-umask). Still no dice. I've pretty much exhausted my know-how in this department. Any other suggestions of how to fix this or where the correct place to set the umask is?
Hi Josh,
Thanks for doing such extensive tests. Have you tried setting the umask in the init script itself?
--nate
Thanks, Josh Nielsen
On Dec 4, 2012, at 11:23 AM, Josh Nielsen wrote:
Hi Nate,
Thanks for the reply. No I hadn't thought to add anything to /etc/init.d/galaxy itself. It is a short enough script that I can paste it below. What would I need to do to edit it with umask settings?
Also I should note, changing the umask in the PAM files actually did change the default permissions for the galaxy user when I did an "su - galaxy" in a bash shell and then created or 'touch'-ed any files (which you could logically expect). But for some reason it didn't seem to make a difference with the directories created in that tmp/ directory even though the galaxy user was given ownership. That made me wonder if something was going on internal to Galaxy, or something else, that was overwriting/ignoring the system umask settings (which actually work fine in a shell environment as the user itself). Maybe I'll look into that ACL stuff Paul mentioned.
Paul's suggestions are worth checking in to. I'd be interested in knowing what the POSIX permissions are on /tmp itself, and what the ACLs are, if any. Those temporary files are created by creating a temporary directory using Python's tempfile.mkdtemp(), which creates them with a mode of 700, which is then masked by the current umask. The change I added in the email you referenced in your original post changes the directory to mode 0777 masked by the umask (after it's created). Depending on how the pieces used in RHEL's startup() shell function handle the environment, you may be able to set it on the line above `daemon ...` inside the 'start)' branch of the case statement. If that doesn't work, you may need to get more creative and do something like: daemon --user $GALAXY_USER "umask 027; ${GALAXY_RUN} --daemon --pid-file=${GALAXY_PID}" Alternatively, you can set it inside /home/galaxy/galaxy-dist/run.sh, since this startup script uses run.sh. --nate
Here is my /etc/init.d/galaxy script:
------------------------ . /etc/rc.d/init.d/functions
GALAXY_USER=galaxy GALAXY_DIST_HOME=/home/galaxy/galaxy-dist GALAXY_RUN="${GALAXY_DIST_HOME}/run.sh" GALAXY_PID="${GALAXY_DIST_HOME}/paster.pid"
case "$1" in start) echo -n "Starting galaxy services: " daemon --user $GALAXY_USER "${GALAXY_RUN} --daemon --pid-file=${GALAXY_PID}" touch /var/lock/subsys/galaxy ;; stop) echo -n "Shutting down galaxy services: " daemon --user $GALAXY_USER "${GALAXY_RUN} --stop-daemon" rm -f /var/lock/subsys/galaxy ;; status) daemon --user galaxy "${GALAXY_RUN} --status" ;; restart) $0 stop; $0 start ;; reload) $0 stop; $0 start ;; *) echo "Usage: galaxy {start|stop|status|reload|restart}" ;; esac --------------
Thanks! Josh
On Tue, Dec 4, 2012 at 9:56 AM, Nate Coraor <nate@bx.psu.edu> wrote: On Dec 4, 2012, at 10:52 AM, Josh Nielsen wrote:
Hello all,
I am having issues downloading HTML files from Galaxy the same as is described in this email chain:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2012-August/010965.html
I am getting the error "(13)Permission denied: xsendfile: cannot open file: /basedir/galaxy_data/database/tmp/tmp8iEccn/library_download.zip" which is indeed a basic filesystem permissions issue. The problem is that the permissions created for that directory and every directory created in tmp/ look like this:
drwx------+ 2 galaxy galaxy 3 Dec 4 09:23 tmp8iEccn
And I have placed the Apache user in the galaxy group, but as you can see no group permissions ever get set by Galaxy on the directories that it creates (it is getting a 700 permissions setting).
As Nate Coraor suggested in the message linked to above, I have tried altering the default umask but I ran into issues with getting non-existant results. I use "sudo service galaxy start" as the galaxy user each time to start the server and a "ps -ef | grep galaxy" confirms that Galaxy is running as the galaxy user. Since I use sudo though I changed the sudoers file to include:
root ALL=(ALL) ALL galaxy ALL=(ALL) ALL Defaults umask_override Defaults umask = 0002
This changed absolutely nothing. Then I started looking deeper into the PAM configuration and added a umask directive to /etc/pam.d/sudo (and also tried it in password-auth-ac and system-auth-ac) like this: "session optional pam_umask.so umask=0002". Still nothing changed in the permissions in tmp/ when I tried to download an HTML file: no group permissions were set. Then I dug deeper still and saw that sometimes if setting the mask in /etc/pam.d/ config files is not enough that you can try to set a system-wide mask in /etc/login.defs (following the suggestion here: http://stackoverflow.com/questions/10220531/how-to-set-system-wide-umask). Still no dice. I've pretty much exhausted my know-how in this department. Any other suggestions of how to fix this or where the correct place to set the umask is?
Hi Josh,
Thanks for doing such extensive tests. Have you tried setting the umask in the init script itself?
--nate
Thanks, Josh Nielsen
Great. I'll give those ideas a shot to see if it gets me anywhere. P.S. You referenced in the email that I linked to a fix in the next release of Galaxy. Is that out yet or still in development? -Josh On Tue, Dec 4, 2012 at 10:44 AM, Nate Coraor <nate@bx.psu.edu> wrote:
On Dec 4, 2012, at 11:23 AM, Josh Nielsen wrote:
Hi Nate,
Thanks for the reply. No I hadn't thought to add anything to /etc/init.d/galaxy itself. It is a short enough script that I can paste it below. What would I need to do to edit it with umask settings?
Also I should note, changing the umask in the PAM files actually did change the default permissions for the galaxy user when I did an "su - galaxy" in a bash shell and then created or 'touch'-ed any files (which you could logically expect). But for some reason it didn't seem to make a difference with the directories created in that tmp/ directory even though the galaxy user was given ownership. That made me wonder if something was going on internal to Galaxy, or something else, that was overwriting/ignoring the system umask settings (which actually work fine in a shell environment as the user itself). Maybe I'll look into that ACL stuff Paul mentioned.
Paul's suggestions are worth checking in to. I'd be interested in knowing what the POSIX permissions are on /tmp itself, and what the ACLs are, if any.
Those temporary files are created by creating a temporary directory using Python's tempfile.mkdtemp(), which creates them with a mode of 700, which is then masked by the current umask. The change I added in the email you referenced in your original post changes the directory to mode 0777 masked by the umask (after it's created).
Depending on how the pieces used in RHEL's startup() shell function handle the environment, you may be able to set it on the line above `daemon ...` inside the 'start)' branch of the case statement. If that doesn't work, you may need to get more creative and do something like:
daemon --user $GALAXY_USER "umask 027; ${GALAXY_RUN} --daemon --pid-file=${GALAXY_PID}"
Alternatively, you can set it inside /home/galaxy/galaxy-dist/run.sh, since this startup script uses run.sh.
--nate
Here is my /etc/init.d/galaxy script:
------------------------ . /etc/rc.d/init.d/functions
GALAXY_USER=galaxy GALAXY_DIST_HOME=/home/galaxy/galaxy-dist GALAXY_RUN="${GALAXY_DIST_HOME}/run.sh" GALAXY_PID="${GALAXY_DIST_HOME}/paster.pid"
case "$1" in start) echo -n "Starting galaxy services: " daemon --user $GALAXY_USER "${GALAXY_RUN} --daemon --pid-file=${GALAXY_PID}" touch /var/lock/subsys/galaxy ;; stop) echo -n "Shutting down galaxy services: " daemon --user $GALAXY_USER "${GALAXY_RUN} --stop-daemon" rm -f /var/lock/subsys/galaxy ;; status) daemon --user galaxy "${GALAXY_RUN} --status" ;; restart) $0 stop; $0 start ;; reload) $0 stop; $0 start ;; *) echo "Usage: galaxy {start|stop|status|reload|restart}" ;; esac --------------
Thanks! Josh
On Tue, Dec 4, 2012 at 9:56 AM, Nate Coraor <nate@bx.psu.edu> wrote: On Dec 4, 2012, at 10:52 AM, Josh Nielsen wrote:
Hello all,
I am having issues downloading HTML files from Galaxy the same as is described in this email chain:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2012-August/010965.html
I am getting the error "(13)Permission denied: xsendfile: cannot open file: /basedir/galaxy_data/database/tmp/tmp8iEccn/library_download.zip" which is indeed a basic filesystem permissions issue. The problem is that the permissions created for that directory and every directory created in tmp/ look like this:
drwx------+ 2 galaxy galaxy 3 Dec 4 09:23 tmp8iEccn
And I have placed the Apache user in the galaxy group, but as you can see no group permissions ever get set by Galaxy on the directories that it creates (it is getting a 700 permissions setting).
As Nate Coraor suggested in the message linked to above, I have tried altering the default umask but I ran into issues with getting non-existant results. I use "sudo service galaxy start" as the galaxy user each time to start the server and a "ps -ef | grep galaxy" confirms that Galaxy is running as the galaxy user. Since I use sudo though I changed the sudoers file to include:
root ALL=(ALL) ALL galaxy ALL=(ALL) ALL Defaults umask_override Defaults umask = 0002
This changed absolutely nothing. Then I started looking deeper into the PAM configuration and added a umask directive to /etc/pam.d/sudo (and also tried it in password-auth-ac and system-auth-ac) like this: "session optional pam_umask.so umask=0002". Still nothing changed in the permissions in tmp/ when I tried to download an HTML file: no group permissions were set. Then I dug deeper still and saw that sometimes if setting the mask in /etc/pam.d/ config files is not enough that you can try to set a system-wide mask in /etc/login.defs (following the suggestion here: http://stackoverflow.com/questions/10220531/how-to-set-system-wide-umask). Still no dice. I've pretty much exhausted my know-how in this department. Any other suggestions of how to fix this or where the correct place to set the umask is?
Hi Josh,
Thanks for doing such extensive tests. Have you tried setting the umask in the init script itself?
--nate
Thanks, Josh Nielsen
On Dec 4, 2012, at 11:57 AM, Josh Nielsen wrote:
Great. I'll give those ideas a shot to see if it gets me anywhere.
P.S. You referenced in the email that I linked to a fix in the next release of Galaxy. Is that out yet or still in development?
The fix was in the September 7, 2012 distribution release, so it'd be a good idea to make sure your release is at least that new. --nate
-Josh
On Tue, Dec 4, 2012 at 10:44 AM, Nate Coraor <nate@bx.psu.edu> wrote: On Dec 4, 2012, at 11:23 AM, Josh Nielsen wrote:
Hi Nate,
Thanks for the reply. No I hadn't thought to add anything to /etc/init.d/galaxy itself. It is a short enough script that I can paste it below. What would I need to do to edit it with umask settings?
Also I should note, changing the umask in the PAM files actually did change the default permissions for the galaxy user when I did an "su - galaxy" in a bash shell and then created or 'touch'-ed any files (which you could logically expect). But for some reason it didn't seem to make a difference with the directories created in that tmp/ directory even though the galaxy user was given ownership. That made me wonder if something was going on internal to Galaxy, or something else, that was overwriting/ignoring the system umask settings (which actually work fine in a shell environment as the user itself). Maybe I'll look into that ACL stuff Paul mentioned.
Paul's suggestions are worth checking in to. I'd be interested in knowing what the POSIX permissions are on /tmp itself, and what the ACLs are, if any.
Those temporary files are created by creating a temporary directory using Python's tempfile.mkdtemp(), which creates them with a mode of 700, which is then masked by the current umask. The change I added in the email you referenced in your original post changes the directory to mode 0777 masked by the umask (after it's created).
Depending on how the pieces used in RHEL's startup() shell function handle the environment, you may be able to set it on the line above `daemon ...` inside the 'start)' branch of the case statement. If that doesn't work, you may need to get more creative and do something like:
daemon --user $GALAXY_USER "umask 027; ${GALAXY_RUN} --daemon --pid-file=${GALAXY_PID}"
Alternatively, you can set it inside /home/galaxy/galaxy-dist/run.sh, since this startup script uses run.sh.
--nate
Here is my /etc/init.d/galaxy script:
------------------------ . /etc/rc.d/init.d/functions
GALAXY_USER=galaxy GALAXY_DIST_HOME=/home/galaxy/galaxy-dist GALAXY_RUN="${GALAXY_DIST_HOME}/run.sh" GALAXY_PID="${GALAXY_DIST_HOME}/paster.pid"
case "$1" in start) echo -n "Starting galaxy services: " daemon --user $GALAXY_USER "${GALAXY_RUN} --daemon --pid-file=${GALAXY_PID}" touch /var/lock/subsys/galaxy ;; stop) echo -n "Shutting down galaxy services: " daemon --user $GALAXY_USER "${GALAXY_RUN} --stop-daemon" rm -f /var/lock/subsys/galaxy ;; status) daemon --user galaxy "${GALAXY_RUN} --status" ;; restart) $0 stop; $0 start ;; reload) $0 stop; $0 start ;; *) echo "Usage: galaxy {start|stop|status|reload|restart}" ;; esac --------------
Thanks! Josh
On Tue, Dec 4, 2012 at 9:56 AM, Nate Coraor <nate@bx.psu.edu> wrote: On Dec 4, 2012, at 10:52 AM, Josh Nielsen wrote:
Hello all,
I am having issues downloading HTML files from Galaxy the same as is described in this email chain:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2012-August/010965.html
I am getting the error "(13)Permission denied: xsendfile: cannot open file: /basedir/galaxy_data/database/tmp/tmp8iEccn/library_download.zip" which is indeed a basic filesystem permissions issue. The problem is that the permissions created for that directory and every directory created in tmp/ look like this:
drwx------+ 2 galaxy galaxy 3 Dec 4 09:23 tmp8iEccn
And I have placed the Apache user in the galaxy group, but as you can see no group permissions ever get set by Galaxy on the directories that it creates (it is getting a 700 permissions setting).
As Nate Coraor suggested in the message linked to above, I have tried altering the default umask but I ran into issues with getting non-existant results. I use "sudo service galaxy start" as the galaxy user each time to start the server and a "ps -ef | grep galaxy" confirms that Galaxy is running as the galaxy user. Since I use sudo though I changed the sudoers file to include:
root ALL=(ALL) ALL galaxy ALL=(ALL) ALL Defaults umask_override Defaults umask = 0002
This changed absolutely nothing. Then I started looking deeper into the PAM configuration and added a umask directive to /etc/pam.d/sudo (and also tried it in password-auth-ac and system-auth-ac) like this: "session optional pam_umask.so umask=0002". Still nothing changed in the permissions in tmp/ when I tried to download an HTML file: no group permissions were set. Then I dug deeper still and saw that sometimes if setting the mask in /etc/pam.d/ config files is not enough that you can try to set a system-wide mask in /etc/login.defs (following the suggestion here: http://stackoverflow.com/questions/10220531/how-to-set-system-wide-umask). Still no dice. I've pretty much exhausted my know-how in this department. Any other suggestions of how to fix this or where the correct place to set the umask is?
Hi Josh,
Thanks for doing such extensive tests. Have you tried setting the umask in the init script itself?
--nate
Thanks, Josh Nielsen
On 04/12/12 16:52, Josh Nielsen wrote:
I am getting the error "(13)Permission denied: xsendfile: cannot open file: /basedir/galaxy_data/database/tmp/tmp8iEccn/library_download.zip" which is indeed a basic filesystem permissions issue. The problem is that the permissions created for that directory and every directory created in tmp/ look like this:
drwx------+ 2 galaxy galaxy 3 Dec 4 09:23 tmp8iEccn
And I have placed the Apache user in the galaxy group, but as you can see no group permissions ever get set by Galaxy on the directories that it creates (it is getting a 700 permissions setting).
Isn't the trailing + character an indication of ACLs being set on the directory? What do the following say...? getfacl /tmp/tmp8iEccn getfacl /tmp If you do have ACLs involved, it may be the case that various masks are being enforced via that mechanism. Paul P.S. I'm not sure that making the galaxy user a "sudoer" would have any effect unless the user was attempting to gain privileges, which would be a pretty scary way of running Galaxy, I would have thought.
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::--- bash> getfacl tmp # file: tmp # owner: root # group: galaxy user::rwx group::rwx other::rwx What enforces these ACLs/where can they be tweaked? 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. Thanks, Josh On Tue, Dec 4, 2012 at 10:06 AM, Paul Boddie <paul.boddie@biotek.uio.no>wrote:
On 04/12/12 16:52, Josh Nielsen wrote:
I am getting the error "(13)Permission denied: xsendfile: cannot open file: /basedir/galaxy_data/database/**tmp/tmp8iEccn/library_**download.zip" which is indeed a basic filesystem permissions issue. The problem is that the permissions created for that directory and every directory created in tmp/ look like this:
drwx------+ 2 galaxy galaxy 3 Dec 4 09:23 tmp8iEccn
And I have placed the Apache user in the galaxy group, but as you can see no group permissions ever get set by Galaxy on the directories that it creates (it is getting a 700 permissions setting).
Isn't the trailing + character an indication of ACLs being set on the directory? What do the following say...?
getfacl /tmp/tmp8iEccn getfacl /tmp
If you do have ACLs involved, it may be the case that various masks are being enforced via that mechanism.
Paul
P.S. I'm not sure that making the galaxy user a "sudoer" would have any effect unless the user was attempting to gain privileges, which would be a pretty scary way of running Galaxy, I would have thought.
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
participants (3)
-
Josh Nielsen -
Nate Coraor -
Paul Boddie