Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!msi.umn.edu!math.fu-berlin.de!fauern!unido!mcshh!abqhh!tpki!oski!schlut
From: schlut@oski.toppoint.de (Olaf Schlueter)
Newsgroups: comp.os.minix
Subject: Maybe a easy solution for the --x--x--x won't exec problem ?
Summary: Just removing one line in fs/stadir.c should be enough.
Message-ID: <32@oski.toppoint.de>
Date: 21 Apr 91 18:16:06 GMT
Lines: 38


Recently someone else reported, that the change of about 3 lines
in both fs and mm sources would solve the problem, that read
permission is a prerequisite for execution in minix.

I want suggest, that just deleting a line in fs/stadir.c would
suffice. During an exec call, permissions are checked twice:
once by fs during an open, next by mm after sucessfully opening
the file.

mm calls fs to open the file to be executed for reading. Before
doing so, it tells fs to change to the working dir of the user
doing the exec call. There is a special check in fs/stadir.c
in the routine do_chdir(), that looks whether the caller is mm.
if so, it sets the eff. uid of mm's fproc entry to the caller
which caused the exec call. mm's normal uid/gid is root/root.

This temporary eff. uid change causes the open call on the
file to be executed to fail. If mm's eff uid would remain
root, the open would succeed even on files without any read
permissions, since fs tries to validate the OPEN call not
the exec call (it does not know anything about an exec call
pending). The check for execution permissions against the
callers uid/gid is done by mm.

I decided to remove the change of the eff uid of mm in
do_chdir. This allows files without read permission to
be executed. 

There is another problem related to the creation of core
files. core files are now dumped with uid/gid root/root.
In original minix they are dumped with uid/gid <actual user>/root.
Since write permissions on dirs or existing core files are
again validated by mm, this is only a small problem.


-- 
Olaf Schlueter, Sandkuhle 4-6, 2300 Kiel 1, Germany, Toppoint Mailbox e.V.
schlut@oski.toppoint.de, olaf@tpki.toppoint.de, ...!unido!tpki!olaf