I forgot to mention my solution assumes that the unix account is the
campus id .. Which in our case it is. We force the galaxy username to be
the campus email. 


campuseid: jdoe  
Campus email: john-...@myuniversity.edu


On 2/1/12 11:07 AM, "Ann Black" <annbl...@eng.uiowa.edu> wrote:

>Hi all -
>I am working on transitioning our test galaxy -> production and this is
>how I have decided to handle unix & galaxy users.
>I have two groups created on our cluster.  1) galaxyadmin and 2)
>galaxyusers.  galaxyadmin is a subset of galaxyusers.
>We have authentication occurring in an apache front to our campus
>id/passwd.  I then place the campus id as well as campus email in the
>request header during the proxy to galaxy.  The email is used as the
>galaxy id.
>I have augmented galaxy code such that when a new user logs onto galaxy
>and galaxy auto-creates the galaxy account, it also kicks off scripts that
>configure the unix account.  It creates a new unix account if it does not
>exist (group galaxyusers), otherwise will augment the existing user's
>default group (keeping all other group relationships) to be galaxyusers.
>I have installed the latest version of openSSH.  I have prevented all
>galaxyusers from sshing into the box, and instead set up a sftp jail.  The
>sftp jail directory is not the user's home directory.  The sshd_config
>also allows me to specify a sftp umask, so when a user puts a file into
>their sftp jail, it will be readable/writeable to anyone in the
>galaxyusers group (note the jail and preventing ssh does not expose the
>files to any other users).
>As part of the scripts that get kicked off in galaxy to create/mod a user
>- I also create the necessary ftp links to galaxy.  I create a symlink
>from galaxy's ftp directory with the galaxy user id (email) to the user's
>jailed sftp directory (username).  This allows galaxy runtime to import
>without problems since the files are galaxyusers group read/writeable.
>My galaxy runs under a galaxy userid (not root) but I have augmented the
>sudoers file to allow for just that id to have access to specific commands
>in order to adjust useraccounts.
>This has been all working in our production prototype testing and we will
>be having a security review on it shortly - but it should be sound.
>Hope this helps!
>>Message: 11
>>Date: Mon, 30 Jan 2012 09:31:15 -0500
>>From: David Hoover <hoove...@helix.nih.gov>
>>To: Sarah Maman <sarah.ma...@toulouse.inra.fr>
>>Cc: galaxy-dev@lists.bx.psu.edu
>>Subject: Re: [galaxy-dev] Unix user account/connection and Galaxy
>>      connection
>>Message-ID: <a0ee343c-c9f5-4039-b684-dd370fb2f...@helix.nih.gov>
>>Content-Type: text/plain; charset="us-ascii"
>>I'd love to know answers to this question as well.  So far, all I've done
>>is create two tools for copying files between Galaxy and a user's
>>personal directories using a rather dangerous setuid executable.
>>I have mulled over two possibilities for this problem.  One is to run
>>Galaxy as root.  The other is for each user to kick off their own
>>personal instance of Galaxy as themselves, but accessing the same main
>>database and file repository.  The latter would require all files be
>>read-write accesible to all users.  Neither is good.
>>On Jan 30, 2012, at 4:29 AM, Sarah Maman wrote:
>>> Dear all,
>>> There is currently no link between an user ssh connection on his own
>>>account (own space on Unix) and the Galaxy connection.
>>> How to run Galaxy on an Unix user account? How to link the data storage
>>>system and the Unix user account (symlink?)?
>>> The goal is to not need to copy or move data.
>>> PS : Thanks a lot to David, Gordon, Brad, Christophe and Nate for your
>>>help on LDAP authentification.
>>> I always try to find a solution (Apache configuration). I will inform
>>>Galaxy list when I will find a solution.
>>> Thanks in advance,
>>> Sarah

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