Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: Ideas for changes to Unix filesystem Message-ID: Date: 16 Feb 91 16:26:15 GMT References: <27B98C54.66F9@tct.uucp> <27BC2E07.673D@tct.uucp> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 35 In-Reply-To: chip@tct.uucp's message of 15 Feb 91 18:52:54 GMT >>Except now you can come back later, say a week later, and re-open the >>file (assuming the file protexns were ok), without the setuid program. > >Well, okay. > >Idea #2: Allow flink() only if you are the owner of the file or the >superuser. That still bypasses directory protections. I suppose one would be hard-pressed to come up with an example of why there would be a file which was owned by you but otherwise not accessible, but I don't like to consider that sort of argument, it only belies the limits of imagination. However, if it were "only the superuser" it would be possible to pass fd's around to setuid programs and let them flink() them. Then it would be up to the setuid application writer to figure out what rules should be imposed, which sounds about right. The potential security pitfalls could be explained in a short paragraph in the manual page, at least in the abstract. The only problem is that the pitfalls are very hard to work around (e.g. does this fd point at a file in an otherwise inaccessible path???), so the result would probably be to not do it on behalf of a non-priv'd program. But it might be of some direct use to priv'd programs. Particularly in combination with that BSD feature of passing fd's around on sockets. (oh boy, now 100 people are gonna say, huh??? look into the access rights stuff in send(2)/recv(2) on a BSD system.) -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD