ccs012@ucdavis.UUCP (Sam A McCall III) (10/08/85)
I have just one small, probably insignificant question. I have begun using strip(1) to remove the symbol tables, etc. from my object files. My question is this: are there any side effects from doing this? Will it cause my process to be swapped out more often because of its now limited storage area, or will it even matter? I have noticed no side effects, but as a novice, I can never be sure... Please e-mail the responses, I may post a summary if I find out anything interesting. -- =============================================================================== Sam A. McCall III University of California, Davis ...!ucbvax!ucdavis!deneb!ccs012 Disclaimer: Yep. I represent all of the University of California schools. Sue me. See if I care. Silly Quote: "You have new mail."
guy@sun.uucp (Guy Harris) (10/08/85)
> I have begun using strip(1) to remove the symbol tables, > etc. from my object files. My question is this: are there > any side effects from doing this? Will it cause my process > to be swapped out more often because of its now limited > storage area, or will it even matter? An executable image consists, roughly, of a header, code/data, and a symbol table. The symbol table is not even looked at by UNIX when it runs the executable image. Stripping the symbol table has *no* effect on executing an image; it certainly doesn't "limit" the "storage area" of the image, whatever that means (a program will get swapped out, or paged out, more often if its address space size increases, or if the *physical* memory available on the machine decreases, or if the address space of other processes on the machine increases - "strip" affects none of these). Guy Harris
eric@amc.UUCP (Eric McRae) (10/10/85)
> I have begun using strip(1) to remove the symbol tables, > ... > ... will it even matter? One note. An unmonitored strip, perhaps stuck inside a find, will silently remove setuid bits throughout the find path...be careful.
guy@sun.uucp (Guy Harris) (10/13/85)
> 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
keith@motel6.UUCP (Keith Packard) (10/16/85)
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
peter@graffiti.UUCP (Peter da Silva) (10/17/85)
> > 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. I doubt strip does this on purpose, because any change to a file resets the set-uid bits, as a security precaution. You may be right that running it as root will leave things alone, though I doubt it. The documentation doesn't say root is immune to this side-effect.
libes@nbs-amrf.UUCP (Don Libes) (10/18/85)
> One note. An unmonitored strip, perhaps stuck inside a find, will
If you strip franz, you won't be able to fasl. (Translation: if you
strip a program that performs linking during runtime, you are fucked.)
Don Libes {seismo,umcp-cs}!nbs-amrf!libesmikel@codas.UUCP (Mikel Manitius) (10/19/85)
> > 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 I just checked strip on System V release 2, it does not change the suid bits, nor the ownership. It really does not do anything to the program other than strip the symbol tables. -- Mikel Manitius - ...{ihnp4|akguc|attmail|indra!koura}!codas!mikel
mikel@codas.UUCP (Mikel Manitius) (10/19/85)
> One note. An unmonitored strip, perhaps stuck inside a find, will > silently remove setuid bits throughout the find path...be careful. Please specify Unix Version, perhaps BSD, not V.2 -- Mikel Manitius - ...{ihnp4|akguc|attmail|indra!koura}!codas!mikel