chouinar@centrcn.umontreal.ca (Luc Chouinard) (03/01/91)
I had the same problem after installing ELM 2.3 on our systems. ELM complained about not being able to write in the MAIL directory. So, I investisgated, and here is what I found: Setgid programs, run into a problem when they want to temporarily return to the user gid (make egid=gid) to check on file accessibility or to start a shell or editor for the user. They can change the current egid to the current gid but they cannnot perform the inverse (i.e. egid=gid of the program). The problem does not exist for setuid programs, because the system calls like setgid or setuid have an additionnal value to check and validate the request. This value is stored in the PROC structure of the process and is called the saved_EUID. When the program perform a setuid call to make uid and euid the same, the system saves the current euid in the saved_EUID. When later on, the program wants to change back to its original euid the system checks if the new euid requested is the same as the saved_EUID to validate the request. The problem is present in the current version of SUNOS (4.1) and IRIX (3.3.1). The saved_EGID field is present in both the SUNOS and IRIX but I suppose that it's the system calls (setpid, setgid, seteuid, setegid) that have not been upgraded. I know that the next major version of BSD UNIX will eliminate the problem and I hope the IRIX 4.0 will too. Meanwhile, the way to bypass the problem is to create a new process (FORK or VFORK) that will perform the setgid and the file accessibility checking and then exit with a corressponding value for the parent process. This is the way that ELM 2.3 use to bypass the problem. At installation time, must of us told ELM to use VFORK, simply because it is present in the IRIX C library. This is where our problems started. The VFORK on IRIX is implemented as a SPROC system call. Further more the sharability flag given in the SPROC call is SALL (i.e. SHARE ALL). This means that, among other stuff, the real and effective user and group ID of the parent and child process are kept synchronized. When the child calls setgid, the parent is given the same values, just like if it had itself done the setgid call. So, to solve the problem, just tell ELM not to use the VFORK call (it will use the FORK call, which is standard in IRIX). (This was said before but I made this posting for the curious) From now on i'll be suspecious about Makefiles or Configure scripts that want to use the VFORK call... PS : I have wrote a program (which I used for this problem) that is the equivalent of SUN's TRACE for the IRIX. I use it a lot for first hand debugging. If enough people are interested in having it (source) I will post it. Just e-mail me to let me know. -- +---------------------------------------------------------+ | Luc Chouinard Computer Center | | System Administrator University of Montreal | | Excuse my english...it's the content that counts ? :) | +---------------------------------------------------------+
hilchey@ucs.ubc.ca (Paul Hilchey) (03/02/91)
chouinar@centrcn.umontreal.ca (Luc Chouinard) writes: > Setgid progams . . . can change the current egid to the current gid > but they cannot perform the inverse (i.e. egid=gid of the program). This works fine if you use setgid instead of setegid. Eg: egid = getegid(); printf("%d\n",getegid()); setgid(getgid()); printf("%d\n",getegid()); setgid(egid); printf("%d\n",getegid()); produces the expected result with Irix 3.3.1. It doesn't work with SunOS 4.1.1, though. A related question: Elm changes the effective uid/gid back to the real ones before calling the access function, though on all the systems I've checked, access is done w.r.t. the real uid/gid. Are there any systems on which that isn't true? ____ Paul Hilchey University Computing Services The University of British Columbia