Different users on the same mapset

[Luca Palmeri]

Seppo Kaitala wrote:

> Hi Luca
>
> Maybe too trivial, but if you put the data in mapset PERMANENT,
> different users can access the data.
>
> Seppo Kaitala

Ok, but nobody other than the owner of the PERM data can modify it. The problem
was to find a way for different users to work with (i.e. read and modify) the same

mapset. In my very special case I solved the problem by rewriting a simplified
GIS.sh and modifing slightly the G__mapset_permissions libes call.

LP




> Luca Palmeri wrote:
> >
> > Dear grass comunity,
> >
> >         Yesterday for the first time since I use grass, I have been
> >
> > faced with an interesting question:
> >
> >         can different users work on the same mapset ?
> >
> > So I tried, I played with unix privileges moved mapsets changed user
> >
> > and group etc. etc. and discovered that finally THE ANSWER IS NO !!!
> >
> > at lest not in grass5beta3 on alinux RH6.0 (posix compliant) platform.
> >
> > Well, this is a little bit strange. Why shouldn't be possible in a
> >
> > multi user environment such as unix to use the same mapset under
> >
> > different usernames (maybe in the same group) ?
> >
> > This could be very usefull especially for large projects whit many
> >
> > people involved in.
> >
> > The problem is in a GRASS GIS library call G__mapset_permissions,
> >
> > that looks like:
> >
> > int G__mapset_permissions (char *mapset)
> > {
> >     char path[256];
> >     struct stat info;
> >
> >     G__file_name (path,"","",mapset);
> >
> >     if (stat (path, &info) != 0)
> >             return -1;
> >
> >     if (info.st_uid != getuid())
> >             return 0;
> >     if (info.st_uid != geteuid())
> >             return 0;
> >
> >     return 1;
> > }
> >
> > Simple, everytime that a call access mapsets data a check is done
> >
> > for the userid of the mapsets file to be equal to that of real and
> >
> > effective ids of the invoking process. So if I own a mapset I can
> >
> > work on it, if I do not own it I cannot regardeless of the unix
> >
> > mapsets files privileges.
> >
> > I have only one question, why ? I do not understand this idea.
> >
> > Ok so I went forward and changed a little bit the code. But if we
> >
> > release this constraint by for example commenting the last two ifs
> >
> > in the call, we will have to check for access permission to the mapsets.
> >
> > This is done at start time in gis_set. I've done some work on that
> >
> > and modified the gis_set and the g.access programs.
> >
> > Anyhow at this stage I do not think it is a good idea to post my bugfixes,
> >
> > that are to be considered much more as tournarounds. A sound understanding
> >
> > of the global grass structure and clear objectives on how to manage mapset
> >
> > permissions are needed in order to produce a proper code.
> >
> > So here I just want to point out that THIS IS AN IMPORTANT ISSUE. Clearly
> >
> > if somebody is interested in having my patch I can send it. But I would first
> >
> > like to understand the developping strategy beneath the G__mapset_permissions
> >
> > call.
> >
> > Comments are welcome
> >
> > LP
> >
> > --> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
> >     Universita' di Padova  TEL: +390498275527 -------
> > -------------------------  FAX: +390498275528 -------
> > --> Think holistic @ the end of the 2nd millenium <--
> >
> >

--
--> Luca Palmeri - Dip. Proc. Chimici dell'Ingengeria
    Universita' di Padova  TEL: +390498275527 -------
-------------------------  FAX: +390498275528 -------
--> Think holistic @ the end of the 2nd millenium <--