Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!ukc!reading!onion!riddle!domo
From: domo@riddle.UUCP (Dominic Dunlop)
Newsgroups: comp.unix.questions,comp.bugs.sys5
Subject: Re: SysV lp spooler a security hole
Message-ID: <484@riddle.UUCP>
Date: Tue, 15-Sep-87 06:32:18 EDT
Article-I.D.: riddle.484
Posted: Tue Sep 15 06:32:18 1987
Date-Received: Sat, 19-Sep-87 18:51:45 EDT
References: <313@pvab.UUCP> <1284@mhres.mh.nl> <1986@kitty.UUCP> <147@stb.UUCP>
Reply-To: domo@riddle.UUCP (Dominic Dunlop)
Organization: Sphinx Ltd., Maidenhead, England
Lines: 40
Summary: Just changing lp to set-gid doesn't work
Xref: mnetor comp.unix.questions:4142 comp.bugs.sys5:230

In article <147@stb.UUCP> michael@stb.UUCP (Michael Gersten) writes:
>If you are having problems with a setuid program not being able to acess files,
>there is an old and working workaround: The set-G-id bit.
>
>Try this:
>	chown bin lp; chgrp lp lp; chmod 02755 lp
>and
>	chgrp lp /usr/spool/lpd; chmod g+w /usr/spool/lpd
>
>Then lpr can queue files in lpd, but still read files based on the owner
>permissions.

Er, sorry.  In my experience, this doesn't work.  I don't know what system
Michael is using (as he references lpd, it probably isn't a vanilla System
V.x port), but I have tried this work-around on a 3B2/400 running V.2, an
NCR Tower XP running V.2, and a Compaq 386 running V.3.  No soap.  The
problem is that programs in the lp suite create control and data files
under /usr/spool/lp with 600 permissions for reasons of security.
Consequently, unless all programs in the suite are setuid lp, they can't
share the files correctly.  I suppose you could fix this up if you had a
source licence -- indeed, my reason for trying on three different systems
was in the optimistic and vain hope that somebody had.

For a program that correctly uses set-gid as a file security mechanism, see
mail.

Incidentally, it occurs to me that the only reason that

	lp < file

gets around the problem is because of a security hole in the UNIX kernel.
Were access rights checked on every read, rather than just when the file is
opened, a setuid program would be unable to read a file with restricted
permissions, even if it had been opened and attached to stdin by a shell
which was able to read it.  Are there implementations of *NIX out there
(secure or networked versions, perhaps) where this work-around really
does fail?

Dominic Dunlop
domo@riddle.uucp  domo@sphinx.co.uk