Date: Wed, 22 Sep 2010 19:36:06 -0500 From: Jim Bryant <kc5vdj.freebsd@gmail.com> To: Atom Smasher <atom@smasher.org> Cc: freebsd-hackers@freebsd.org, Ivan Voras <ivoras@freebsd.org> Subject: Re: How to disallow logout Message-ID: <4C9AA0F6.6040509@gmail.com> In-Reply-To: <1009110004520.2000@smasher> References: <AANLkTim4OG2124dVtEHFSR06c7sF-nnMA7bgfPApTywk@mail.gmail.com> <i6d5kp$atl$1@dough.gmane.org> <1009110004520.2000@smasher>
next in thread | previous in thread | raw e-mail | index | archive | help
Atom Smasher wrote: > On Fri, 10 Sep 2010, Ivan Voras wrote: > >> 1) power outage of the server >> 2) power outage on the client >> 3) network problems (ssh or TCP connection drop) >> 4) administrative command (e.g. root executes "killall $shell") >> >> ? >> >> I don't think there is a way to protect from all of those, so any >> effort in protecting from only part of the problem looks useless. > ======================== > > you forgot cosmic rays, nuclear war and zombie apocalypse, among other > failure modes. *NOTHING* is capable of protecting against everything; > a good solution will most always have pitfalls; as a > sysadmin/engineer/manager one has to either accept the pitfalls or > find a more acceptable solution, which usually means different > pitfalls. that doesn't mean a given solution is useless. > > Bah. since you mentioned .logout, i'm assuming you are using tcsh. what i would suggest is that you create an md and check out the files into that. this solves the power fail issue completely, also, it solves the main issue. have the logout script simply umount and mdconfig -d the ramdisk. also, this way, security is enhanced because no fragments, even of deleted files, are left on disk after logout. the only question i have is if a bzero is done before returning the ram to the os, if not, simply dd if=/dev/zero of=/dev/md0 bs=whatever to be sure that the ram formeerly contained in the ramdisk isn't readable by later procs. have you considered trustedbsd? it should perform the bzero by default. TBSD MAC is in fbsd these days to control access to the mountpoint, but that might not help if you are worried about a lifted disk, MAC don't mean shit without physical security, the kind involved in the environments for which it was commissioned.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C9AA0F6.6040509>