klamer@mi.eltn.utwente.nl (Klamer Schutte) (05/06/91)
In <1991May2.192802.17885@syd.dit.CSIRO.AU> evans@syd.dit.CSIRO.AU (Bruce.Evans) writes: discussion about another exec problem similar, but not relevant now. ->I have already fixed the bug for 1.6, so further discussion is mostly ->academic. Wait to find the bugs in my fix :-). ->I used the trick of opening the file with MM as root. Actually, this is ->the natural way - switching to the user's context is tricky and had ->other bugs. I rejected MM's checking of permissions on aesthetic grounds - ->only FS really knows how to do it. Also, it saves code, and I wanted to ->exercise the fix for another 'x' permissions bug in FS (at least one 'x' ->bit was required to search directories even for root, because 'x' for ->execute and 'x' for search-directory were confused). Seems a good idea. ->I called access() from MM to check the permissions. Since access() checks ->the whole path, the new bug is avoided. There are 2 problems with access() ->that make it useless for applications but don't matter here: ->1) It uses the real ids and not the effective ids. Fixed by making the ->real ids = the effective ids in the partial switch to the users context. This seems OK. ->2) Races. One user might access() a file and then open() it while another ->user might change the file permissions in the middle. But a user can never ->win such a race with MM. Oops, maybe it can: >> discription how it can && minix panics. << How about this schema: drop the access() call, and let MM only make a open() call to FS. This open() has to be special in these fields: 1) It should use the user programs effective ids. 2) It should check for exec, and not for read permissions. Dropping the access() call cancels the possible race conditions. And combining the two calls speed up the whole process. Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer