Unix group permissions and MetaEdit+

Background

The MetaEdit+ manual requires that all users of multi-user MetaEdit+ on Unix should belong to the same group, as defined by their primary group in /etc/passwd. This is because shared access to files in the MetaEdit+ repository is by group permissions: the only way to allow several users to access a file, but not all users. It is not sufficient to simply create a new group (e.g. 'metagrp') in /etc/group and add MetaEdit+ users to that, because although users could read files in the MetaEdit+ repository on the basis of their being in the metagrp group, and the repository files being owned by that group, when a user writes a file (create or change) the file takes on the group ownership of the user's primary group. Thus the group ownership of the files in the repository would change as they were used, meaning other MetaEdit+ users (not part of that user's primary group) would no longer be able to access those files.

This situation can however be annoying: MetaEdit+ users probably did not all have the same primary group in /etc/passwd prior to MetaEdit+ being used, and forcing changes to their primary groups may produce problems elsewhere.

Solution

The setgid bit in directories has a special meaning in BSD Unix, and this behaviour is also emulated by some other Unixes (at least SunOS and Solaris: you can test your OS). When a directory has setgid on, files written by a user in that directory will have the same group owner as the directory, rather than the primary group of the user. Thus we can create a new secondary group (e.g. 'metagrp') in /etc/group, add all MetaEdit+ users to it, set the group owner of the MetaEdit+ repository directories and files to 'metagrp', and set the setgid bit for all repository directories and subdirectories (including the root directory where artbase.roo is).

E.g. if your artbase.roo directory is in /home/metadir, add the following line to /etc/group, replacing the number with a new unique group number, and the users mepuser1 etc. with the names of the MetaEdit+ users (of course, since you're making changes to the system and your MetaEdit+ repository, you should be careful, log what you're doing and have backups!).

metagrp:*:12345:mepuser1,mepuser2,mepuser3

Then become root, go to the directory where artbase.roo is, set the ownership, permissions and setgid bit for that directory, artbase.roo, and recursively for all database subdirectories and files there. Change the names of the user and database directories (i.e. those containing manager.ab) appropriately. The example below is for csh in SunOS 4.1.3 - you may need to make changes for your shell and OS, e.g. for sh use 'for dbdir in db1 db2 db3 do .... done'.

su
cd /home/metadir
chown mepuser1.metagrp . artbase.roo
chmod 770 .
chmod 660 artbase.roo
foreach dbdir (db1 db2 db3)
  chown -R mepuser1.metagrp $dbdir
  chmod -R 660 $dbdir
  find $dbdir -type d -exec chmod 770 {} \; -exec chmod g+s {} \;
end

The net result should be something like this:

ls -ldg . artbase.roo db1 db1/areas db1/areas/mcc db1/areas/mcc/mcc.aob db1/manager.ab

drwxrws---  2 mepuser1 metagrp      512 Oct 17 23:14 .
-rw-rw----  1 mepuser1 metagrp     2342 Oct 17 23:14 artbase.roo
drwxrws---  2 mepuser1 metagrp      512 Oct 17 23:14 db1
drwxrws---  2 mepuser1 metagrp      512 Oct 17 23:14 db1/areas
drwxrws---  2 mepuser1 metagrp      512 Oct 17 23:14 db1/areas/mcc
-rw-rw----  2 mepuser1 metagrp     2412 Oct 17 23:14 db1/areas/mcc/mcc.aob
-rw-rw----  2 mepuser1 metagrp     2412 Oct 17 23:14 db1/manager.ab

You should of course test these changes by using MetaEdit+: make sure all users can work with the repository, and that when they commit their changes, the directories and files for changed projects/areas do not lose their permissions, group owner or setgid bit (the user owner will change to be that of the user who last committed a change in that area, but that is normal). In particular, you should make sure if you have users on non-Unix platforms that the changes made from their OS through their network software do not upset these settings.

Testing your OS

To find out whether your OS has this behaviour for the setgid bit, you must have a user who belongs to two groups, e.g. 'someuser' in groups 'main' (defined in /etc/passwd) and 'other' (defined in /etc/group). Make two directories owned by him and his 'other' group, and make one setgid. Create a new file in each directory, and see whether the one in the setgid directory is owned by the 'other' group. E.g.:

su
cd ~someuser
mkdir setgid nosetgid
chmod g+s setgid
chown someuser.other setgid nosetgid
su someuser
cat >setgid/tmp
typesometext
^C
cat >nosetgid/tmp
typesometext
^C
ls -lg setgid/tmp nosetgid/tmp
exit
rm -R setgid nosetgid
exit

If the 'ls -lg' step gives group ownership for setgid/tmp as 'other' (and nosetgid/tmp as 'main') then the setgid bit will work on your system as described above. If you have users on non-Unix platforms you should also check that this behaviour is the same from their OS through their network software.