Access restrictions for Ace

zgudmunt at my-deja.com zgudmunt at my-deja.com
Thu Oct 21 05:24:40 EST 1999


   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
write.
    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

                                Gudmundur


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
it
> 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
id
> (that owning the database files) when reading or writing files in the
> database directories.  All other file operations, including parsing
and
> 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.
>
> Richard
> ---
>


Sent via Deja.com http://www.deja.com/
Before you buy.




More information about the Acedb mailing list