Thanks a lot, both of you (Dave & Richard). It was the setuid-thing
that confused me. I have multiple project groups that need to be kept
private, each in their corner, so think I'll use the user group method
partially, meaning that the top ace-dir can be made chmod 770 and thus
read-closed for anyone outside the group (and ace of course). But then
the setuid-method takes care of which users in the group are allowed to
I may switch to the server/client later, but I have so few users pr.
group at the moment that it's working fine. I may want, however, to make
some kind of a Java/CORBA interface later on, at least for some
(non map-display) functions. But are there no plans for adding writing
capabilities to the Ace CORBA interface?
Thanks again, I appreciate it
In article <199910202221.XAA14233 at griffin.sanger.ac.uk>,
rd at sanger.ac.uk (Richard Durbin) wrote:
> There have over the years been a number of solutions to giving write
> access to a group of people for an acedb database. By far the most
> sound and least problematic has been the following:
>> make the executable setuid, by chmod 4755 xace tace
> make all the database/* files, wspec/* files 644 as normally
> add user ids you wish to have write access to wspec/passwd.wrm
>> The code expects this setuid mode, and does the following: on startup
> recovers the true userid of the user running the program, and switches
> back effective user-id to that user. It only switches to the setuid
> (that owning the database files) when reading or writing files in the
> database directories. All other file operations, including parsing
> exporting data, are done with the true user id.
>> Solutions using Unix groups require very careful setting of umask that
> has proven very hard to administer and enforce. We strongly advise
> you to switch to the approach described above.
>> Alternatively, use aceserver/aceclient, which avoids these problems.
Sent via Deja.com http://www.deja.com/
Before you buy.