Marco Lackovic wrote: > On Mon, May 10, 2010 at 1:24 AM, Martin Feller <[email protected]> wrote: >> Ok, my first guess is, that the mapping in the grid-mapfile is not as you >> think it is, i.e. the DN of the user who submits the transfer request >> is mapped to another user and not to the user 'globus'. >> You mentioned that it is, but maybe worth double-checking. > > The procedure chosen for the system I am using is to have local > accounts, on every grid node, for all grid users and then have them > mapped to their own local accounts in the grid-mapfile. Users were > then added to the globus group so that they could access common files > located in the /home/globus directory. > > I suspect this might not be the proper way to do things and I am in a > position to change them. Do you advice against that procedure? Is it > customary to map instead all grid users to the user 'globus'? Can you > suggest a good reference on this topic? >
This approach looks fine to me. We use the same approach in a project I work on: All users have individual accounts, but are members of various local unix groups. Each group reflects a project. Depending on group membership they can access project data being owned by that group, or not. There is another approach where all users share a community credential which is augmented with user-specific information (attributes). Authorization decisions are then done by callouts which check the the user-specific attributes. I don't know enough about it to give you detailed information about this, but if you are interested i could maybe find documentation pointers or forward this to folks who know more about this. Or maybe there's even somebody on this list who can provide input on this! > >> If you have control over the machine where the GT server is running and the >> system is not a production system: create a grid-mapfile with just one >> mapping of your DN (you can e.g. get your DN by running the command >> 'grid-proxy-info -identity' on the client-machine) to the local user >> 'globus' and see if that works. > > In the end I have found out that "Can't do MLST on non-existing > file/dir" error message was actually a permission problem: the file > permissions were 660 (rw-rw----) but the local user, to which the grid > user was mapped to, didn't belong to the globus group. Assigning the > local user to the globus group fixed the problem in all the machines > but one on which I still got that error, despite the user does belong > to the globus group. > > Glad to hear that it works now on most machines. Hard to tell for me why this one machine still causes problems. I hope you can figure it out. Martin
