loverso@sunybcs.UUCP (John Robert LoVerso) (09/20/85)
From: peter@rlgvax.UUCP (Peter Klosky) 16 Sep 85 <764@rlgvax.UUCP> > > For security make your /tmp file 0600 mode. > > /tmp is world writeable. This means that anyone can unlink tmp files. > In particular, my application wants to pass state data from a child > process to a parent prodcess via a tmp file that the child creates, > and there are windows of vulnerability in this scheme, due to the unlink > trouble. Easy. have your application make a subdirectory in /tmp, and then place a file within that subdir. As long as your subdirectory is not world writeable, you can place tmp files there w/o having a window of vulnerability. I also changed /etc/rc to clear /tmp with an rm -r John -- John Robert LoVerso @ SUNY/Buffalo Computer Science (716-636-3190) LoVerso%Buffalo@CSNET-RELAY -or- ..!{watmath|dual|decvax}!sunybcs!loverso
mike@whuxl.UUCP (BALDWIN) (09/25/85)
> > /tmp is world writeable. This means that anyone can unlink tmp files. > > In particular, my application wants to pass state data from a child > > process to a parent prodcess via a tmp file that the child creates, > > and there are windows of vulnerability in this scheme, due to the unlink > > trouble. > > Easy. have your application make a subdirectory in /tmp, and then place > a file within that subdir. As long as your subdirectory is not world > writeable, you can place tmp files there w/o having a window of vulnerability. But anyone can still move the directory in /tmp, and put another one in its place. The problem is still there. -- / These are \ Michael Baldwin | only >my< | AT&T Bell Labs \ opinions. / {at&t}!whuxl!mike
maurice@nmtvax.UUCP (09/25/85)
> >I also changed /etc/rc to clear /tmp with an rm -r > However, you should realize that if /tmp is a filesystem in its own right, the lost+found directory will be consumed with the rm -r command. Do you really want to do that? Of course it doesn't take much to bring it back, but fsck will sorely miss it. Roger Levasseur New Mexico Tech
dave@lsuc.UUCP (David Sherman) (09/27/85)
In article <2279@sunybcs.UUCP> loverso@sunybcs.UUCP (John Robert LoVerso) writes: >From: peter@rlgvax.UUCP (Peter Klosky) 16 Sep 85 <764@rlgvax.UUCP> >> > For security make your /tmp file 0600 mode. >> >> /tmp is world writeable. This means that anyone can unlink tmp files. >> In particular, my application wants to pass state data from a child >> process to a parent prodcess via a tmp file that the child creates, >> and there are windows of vulnerability in this scheme, due to the unlink >> trouble. > >Easy. have your application make a subdirectory in /tmp, and then place >a file within that subdir. As long as your subdirectory is not world >writeable, you can place tmp files there w/o having a window of vulnerability. Well, you can't LOSE your data, but you can still have it misplaced for you. All the "bad guy" has to do is mv /tmp/yourdir /tmp/nowhere, and your parent process will never find it. Dave Sherman The Law Society of Upper Canada Toronto -- { ihnp4!utzoo pesnta utcs hcr decvax!utcsri } !lsuc!dave
henry@utzoo.UUCP (Henry Spencer) (09/27/85)
It's something like a two-line kernel mod to make unlink() refuse to work
if the directory has the sticky bit on and the invoker is not the owner
of the file (or the superuser). Then you just sticky-bit /tmp.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryrick@seismo.CSS.GOV (Rick Adams) (09/28/85)
If /tmp is a filesystem, why screw around. Just to a mkfs. You can't hide from that. I set up a machine at Purdue to do that. I got tired of the students trying to be clever with /tmp/..., etc. It ended it. ---rick
pls@soessx.UUCP (P.L.Sullivan) (09/28/85)
In article <2279@sunybcs.UUCP> loverso@sunybcs.UUCP (John Robert LoVerso) writes: >From: peter@rlgvax.UUCP (Peter Klosky) 16 Sep 85 <764@rlgvax.UUCP> >> > For security make your /tmp file 0600 mode. > >I also changed /etc/rc to clear /tmp with an rm -r > If you have the luxury of a separate /tmp file system it is even more efficient and often takes less time than "rm -r" to simply do a "mkfs" over the old one. The big advantage is that the free list gets reassembled for optimum access rather than being frag'ed all over the file system. (I know - If you don't, "fsck -s..." does just about as much good (:-). ================================================================== Pat Sullivan - {akgua|akguc|ihnp4}!soessx!pls - voice 404-257-7382
mikel@codas.UUCP (Mikel Manitius) (10/04/85)
> > > >I also changed /etc/rc to clear /tmp with an rm -r > > > > However, you should realize that if /tmp is a filesystem > in its own right, the lost+found directory will be consumed with the > rm -r command. Do you really want to do that? Of course it doesn't take > much to bring it back, but fsck will sorely miss it. > > Roger Levasseur > New Mexico Tech fsck never misses a lost+found dirrectory, and you probably wouldn't care to recover any lost files in /tmp anyway. Note one point, if /tmp is on a seperate filesystem, make sure that it gets mounted before you do the rm -r /tmp, otherwise you will nuke /tmp and there will be no place to mount it. It is also probably safer to "cd /tmp; rm -r .", even though you can't remove a directory on which a filesystem is mounted, it is not a good idea to try. -- ======= Mikel Manitius ==----===== AT&T ...!{ihnp4!}codas!mikel ==------===== Information Systems (305) 869-2462 ===----====== SDSS Regional Support AT&T-IS ETN: 755 =========== Altamonte Springs, FL My opinions are my own. =======
chris@umcp-cs.UUCP (Chris Torek) (10/08/85)
> fsck never misses a lost+found directory, and you probably wouldn't > care to recover any lost files in /tmp anyway. Not so! Not, at least, in 4.2BSD. In particular, if `fsck' wants to reconnect a file, but there is no lost+found, it will abort a `preen' style fsck rather than clearing the inode. And `ex'---and thus vi---temporary files are stored in /tmp; but they are still useful, after a crash, for recovering most if not all of your editing sessions. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu