Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site motel6.UUCP
Path: utzoo!decvax!tektronix!reed!motel6!keith
From: keith@motel6.UUCP (Keith Packard)
Newsgroups: net.unix
Subject: Re: strip(1): will it goof anything?
Message-ID: <186@motel6.UUCP>
Date: Wed, 16-Oct-85 04:03:31 EDT
Article-I.D.: motel6.186
Posted: Wed Oct 16 04:03:31 1985
Date-Received: Thu, 17-Oct-85 19:10:51 EDT
References: <127@ucdavis.UUCP> <2862@sun.uucp> <130@amc.UUCP> <2886@sun.uucp>
Reply-To: keith@motel6.UUCP (Keith Packard)
Distribution: na
Organization: 5440 SE 41st, Portland, OR
Lines: 40
Xref: tektronix net.unix:06306 
Summary: 

In article <2886@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>> One note.  An unmonitored strip, perhaps stuck inside a find, will
>> silently remove setuid bits throughout the find path...be careful.
>
>Or run it as "root".  I can't speak for System V (thanks to COFF, "strip"
>consists of no less than 8 ".c" files, and I'm not about to see how it does
>the stripping), but it may not remove the setuid bits there.
>
>	Guy Harris

It depends on the configuration of the kernel; version 7 and derivatives
have a kernel define (INSECURE) that, if not defined, causes all
set-uid, set-gid bits to be cleared on *any* modification to the file.
Many commercial unix systems (Ultrix for example) do define this flag so
running the find on them will cause the set-uid bits to be cleared, 
even when running as root.  For example, in my 2.9 kernel we have
the little bit of code (from rdwri.c):

writei(ip)
register struct inode *ip;
{
	.
	.
	.

#ifndef	INSECURE
	/*
	 * clear set-uid/gid on any write
	 */
	ip->i_mode &= ~(ISUID|ISGID);
#endif

Not having the 4.2 truncate call I cannot tell if that will as
well clear the bits but I suspect they were overly cautious...

Of course, most hand built kernels do not define INSECURE as it
isn't a problem if you are cautious about certain set-uid programs.

keith packard
...!tektronix!reed!motel6!keith