Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!NEXTASY2.EECS.WSU.EDU!dwatola
From: dwatola@NEXTASY2.EECS.WSU.EDU (David Watola)
Newsgroups: comp.sys.next
Subject: ownership of automounted volumes
Message-ID: <9106222222.AA16116@nextasy2.eecs.wsu.edu>
Date: 22 Jun 91 22:24:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 31
X-Unparsable-Date: Sat, 22 Jun 91 15:22:14 GMT-5632:48


very recently, some people have pointed out that making automounted
floppies or opticals owned by whoever is on the console (and ignoring
actual written ownerships) is a security risk.

but consider the alternative.  i could make a setuid root script or
program that gave me a subshell here on my machine at home, pop it
on a floppy (or optical disk if i had one) and bring it to school.
if the written ownerships were respected, then i would magically
inherit root privileges.  neat, huh?  so which security risk is worse.

there would also be the problem that internal user numbers for the same
user vary from system to system.  i suspect that this is the cause of
some of the problems i have transferring writenow files between machines.
often, when i try to open a file i have transferred, it will tell me that
the file is locked by some other account that never even touched the file!!!
apparently, writenow maintains (in the file itself) a record of who used
it last for this purpose.

hmmmm...  i'm a little to lazy to try this out myself right now, so i'll
submit it to all you readers.  if you put a setuid root executable on a
floppy and it gets automounted by the workspace, does it still come up
as a  setuid file?  and setuid who?  i dimly recall that once i tried
putting a setuid root file on a floppy and it refused to work, but i was
in no mood to find out why.  and how about opticals?  (i couldn't check
this out--i don't have root access to a machine with an optical drive).

dave watola
dwatola@nextasy2.eecs.wsu.edu
dwatola@yoda.eecs.wsu.edu