Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!ditsydh.syd.dit.CSIRO.AU!evans
From: evans@syd.dit.CSIRO.AU (Bruce.Evans)
Newsgroups: comp.os.minix
Subject: Re: Maybe a easy solution for the --x--x--x won't exec problem ?
Message-ID: <1991May2.192802.17885@syd.dit.CSIRO.AU>
Date: 2 May 91 19:28:02 GMT
References: <32@oski.toppoint.de> <1991Apr30.185457.29113@email.tuwien.ac.at>
Organization: CSIRO Division of Info Tech, Sydney, Australia
Lines: 61

In article <1991Apr30.185457.29113@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes:
>schlut@oski.toppoint.de (Olaf Schlueter) writes:
>
>>[Proposes that FS should open files to be exec'ed with euid of mm
>>instead of user so that non-readable files can be executed]
>
>There is a security problem with this approach (If you care about
>security). Under Minix and Unix, to execute a program you do not only
>need execute-permissions for the file, but also search-permissions for
>all the directories leading to it. If FS opens the file with MMs

The original proposal depends on MM checking the permission bits on the
file itself. But as Peter points out, this doesn't check the permissions
for the rest of the path.

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).

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.

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:

    MM:    access("/fd/foo", ...);	/* floppy mounted on /fd */
    MM:    waits for FS
    FS:    waits for floppy
    USER:  unlink("/fd/foo");
    USER:  waits for FS
    FS:    finishes access() and replies to MM
    FS:    either it returns to MM here or it does the unlink
    MM:    [actually it would do some tell_fs() calls here]
    MM:    open("/fd/foo", ...) after access() succeeded
    MM:    waits for FS
    FS:    do the unlink if not already
    FS:    do the open. It fails!
    MM:    panics

Doing the open before the access may be a good enough fix. The open is done
as root so it will succeed if the file exists. Too bad if the permissions
changed just after the file was opened; the new permissions are just as valid.

What about other races between MM and FS? It's unfortunate for them to get
tangled up like this just because they are separate. FS has complete
information about the permissions when it does the open, but the open()
interface does not provide a way to return it.
-- 
Bruce Evans		evans@syd.dit.csiro.au