Path: utzoo!attcan!uunet!ogicse!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Ideas for changes to Unix filesystem
Message-ID: <17899:Feb511:45:5191@kramden.acf.nyu.edu>
Date: 5 Feb 91 11:45:51 GMT
References: <1991Jan30.143326.16676@socs.uts.edu.au> <1991Feb04.045330.779@iecc.cambridge.ma.us>
Organization: IR
Lines: 22

In article <1991Feb04.045330.779@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes:
> In article <1991Jan30.143326.16676@socs.uts.edu.au> jeremy@socs.uts.edu.au (Jeremy Fitzhardinge) writes:
> >1 - a flink(char *path, int fd) system call/operation.
> Currently, a setuid program can open a file, turn off its setuid-ness, and
> exec some other program which can use the open file but not link, chmod, etc.
> This is pretty pointless for disk files, but can sometimes be useful if the
> file is a device or network file.  Being able to invent a name for any open
> file passed to you introduces possible protection holes.  Ugh.

Yeah, but if you give flink() the obvious link() semantics then there's
no security problem.

> I'd be
> interested to hear what real problems this is intended to fix.

Well, you might create temporary files with fdtemp(), manipulate them
outside the directory tree, and then flink() them in their final state.
(fdtemp() would have to take a directory argument so that it could
assign a filesystem to the file.) This prevents several potential
security holes and makes it easier to synchronize separate applications.

---Dan


Brought to you by Super Global Mega Corp .com