johnhi@teksce.SCE.TEK.COM (John Higley) (12/08/87)
I have a problem that I would like to pose to "the experts". I have written an application that may be run at any time any day and updates some files. The application places locks on the files when this user needs to write. For any user to be able to update these files, it is necessary that the application be run either suid or sgid to 'me'. This is fine. At certain times during the day a 'master' process needs to take the daily update files and use them. For that to happen successfully, I must kill any users of the original application. (Some of the data files are large, and having processes attached to the files causes old files to remain open even after they are removed, as you are no doubt aware.) This causes the need for the application to be run suid to me. Again, this is fine. Now for the problem: The user of the application wants to be able to create an output file for certain information that he has found. Unfortunately, the output file belongs to me (suid) and I do not have write permission in his directory. What I would like to occur is that the output file belong to the real user (him) not the effective user (me). Any ideas? Any questions? (sometimes I don't say what I thought I said) Maybe the answer lies in how to kill the application so that it can run sgid instead of suid. Right now I (the master process) send the USR1 and USR2 signals, which the application is made to interpret. John Higley johnhi@teksce.SCE.TEK.COM.UUCP
jrb@petro.UUCP (Jon Boede) (12/09/87)
In article <884@teksce.SCE.TEK.COM> johnhi@teksce.UUCP (John Higley) writes: >I have a problem that I would like to pose to "the experts". *I* probably shouldn't be replying to this, but... :-) >Now for the problem: The user of the application wants to be able to create >an output file for certain information that he has found. Unfortunately, the >output file belongs to me (suid) and I do not have write permission in his >directory. What I would like to occur is that the output file belong to the >real user (him) not the effective user (me). I have delt with this problem by having the program fork(2) itself and then have the child change it's u/gid back to what it's supposed to be... int status; switch (fork()) { case 0: setgid(getgid()); setuid(getuid()); /* open, write and close the file. */ exit(successful ? 0 : 1); case -1: perror("reality collapse"); break; default: wait(&status); /* check status to make sure. */ } One other trick along these lines that I liked was where the effective user and the real user couldn't write into each other's directories but I wanted the real user to be able to update "his entry" in the future... what I did was link("/usr/effective/file","/usr/tmp/fileXXXXXX"); fork(); child process: setuid(getuid()); setgid(getgid()); link("/usr/tmp/fileXXXXXX","/usr/real/the.copy"); unlink("/usr/tmp/fileXXXXXX"); Kind-of like building a brige over a 20' wide river by throwing two 10' ropes from opposite banks :-) If there's a better way to do this, I'm *very* interested -- mail me. Hope it helps, Jon -- Jon Boede ...!{gatech,ihnp4,ssbn,swrinde,tness1,utanes}!petro!jrb 512/599-1847 2555 N.E. Loop 410, #1403, 78217 "People who are incapable of making decisions are the ones who hit those barrels at freeway exits."