This may be pretty obvious, but I've had several system users encounter the same problem (although not with a MUD) regarding group permissions. They forget to use the newgrp command, to switch their current group to the one required. For argument's sake, let's assume I have a circle account, and the /src and /lib directories are all included in group "coder", with the appropriate permissions. On our system, the user starts in a default group (staff), and when they try to access the /circle/lib files from a non-circle account, it will say permission denied, since they are currently in the "staff" group. They often forget to switch to the "coder" group by issuing a "newgrp coder" at the shell prompt, which makes their current group "coder". After they do this, they are able to manipulate all files which belong to group coder, and have the right permissions. This may or may not be your problem, but our users encounter this regularly. --- Christopher Herringshaw | University of Michigan Medical Center Special Projects Development | 1500 East Medical Center Dr. B1-240TC xxviper@umich.edu | Ann Arbor, Michigan 48109-0704 http://www.umich.edu/~xxviper | +0101 (313) 747-2778 On Tue, 18 Jul 1995, Idle Process wrote: > > We're just starting up here, and we have basically only two folk with > access to the code now, and we both have root access. However, we will > not be wanting ALL our coders to have root :) > > What sort of user/group structures and permissions are being used out > there? I tried setting up a 'mud coding group' that myself and another > coder are members of, and chmoding everything so the group has rights to > it, but the autorun script still messes up everytime one of us runs it - > the other can not, because of rights problems. Are people creating a > special user for working on the mud? Or several users with the same UID > but different pw's? > > Any info would be appreciated. > > -price > >
This archive was generated by hypermail 2b30 : 12/07/00 PST