From owner-freebsd-questions@freebsd.org Mon Feb 24 17:22:45 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E042523C01A for ; Mon, 24 Feb 2020 17:22:45 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48R85b22Zqz47W9 for ; Mon, 24 Feb 2020 17:22:42 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.5.94.235]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPA (Nemesis) id 1MmU5P-1joj4h3lvl-00iREE; Mon, 24 Feb 2020 18:22:31 +0100 Date: Mon, 24 Feb 2020 18:22:29 +0100 From: Polytropon To: "Kevin P. Neal" Cc: Jos Chrispijn , freebsd-questions@freebsd.org Subject: Re: rm | Cleaning up recycle bin Message-Id: <20200224182229.1b670c54.freebsd@edvax.de> In-Reply-To: <20200224145317.GA9130@neutralgood.org> References: <20200223184908.b35d656a.freebsd@edvax.de> <20200224145317.GA9130@neutralgood.org> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:PNzJa+3wAn6XKhuENqS67LAgDCfVOwU+PchUQO/qSweMKvaPE2j +HJ3nb9TOJfowX2zRZNqXA6gsRw+4NGS0B9pz0XjmuwBwfWP6G+KCS5CwWdgwimdKklFadW aRwk+xksabSVWTAVthwmryAxXxCRCbY50eby05JgOH0ORVNMGIHujivvw0UsaFo2qtNab4e qu4IEjXhq8wesQqQOUVXg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:M1aOW05eDZI=:iBHvBpY4WwfJVlo0q8ZaWW v5NfxiHHfuQ5ivl8hn5ijbfWZk7uD7zPu85YwBx9jCn5uegrbg7GaQaQyFFRD6aVpVh3Kt0GK PdHsFVQ+5gHqTOpbMEcL6UZ6Mu5KtqrlHMakueaJQ18OYChqCtKKB0t2HdcEA9VaSQAYKeGwR yOrVe4tGMsowvrjiJZNhQgT6bON/jih3rhbyzTY10ATaW+ACiv2VUIfhjn0CPhj/oOOCjq9s7 K1pcTsxEF9qyvtUjaue96u1teckXIjSidRpryVOrJfUH95fBZ81xnqmAcA988Nq7B7BRVqTzz xDlZvlvxbKOPMNqN23BbK/14qSn2kU5j0LAKQ5Wl6GTY+IXasPVsWK9A5xhIef+rAHnEaiJ0c mT9rn7d85VgJrrMwI+j4ANnK2AlWnesUcL+LG12z4Wlw7zB2kk+46bIyz3h/glidyCRkPHChA GFADEBBW69EQEBzlOBkr5Xi/8q81emmnf59GxjokVMd5wYNV9oszNAVTvv++spJNu9Ngl9o+E /DXFFhF2JSTCQUtWKm8k/p2FzfaXlsf3tRGvfh2OLHzgPvADUetwuEEJCB6JW20w1ieN9nlYX T3Bvkcz6TIyZ6vvnICexUP64q/+zXb0gyy6zgKLomEkhKuLCB7sRbVKF6TrK16CTjKsPwnm6b W4WeV+eI933Gs4j8Zes3LAqLC1IA49FD114QzyoHnEzC3qf+nXtj3Kk8wOeBYX4OV4/tkpQPt Ti7l4TzdWyHUmIbKi43Eb0cnlGfWaQPhqv1hfnFSzJ6dp+bDGL6U0ZReCKyo00CD+E0yWKQY9 DLx/xLZqMlDy9Y1kLSz5tTqv1KUbjzZgDMy2f+HyUqxi37uQuacikANi9Wbp54asK03MlCF X-Rspamd-Queue-Id: 48R85b22Zqz47W9 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 217.72.192.75) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:217.72.192.0/20, country:DE]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[235.94.5.178.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.983,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.995,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[75.192.72.217.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.37)[ip: (-0.68), ipnet: 217.72.192.0/20(0.33), asn: 8560(2.19), country: DE(-0.02)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 17:22:46 -0000 On Mon, 24 Feb 2020 09:53:17 -0500, Kevin P. Neal wrote: > On Sun, Feb 23, 2020 at 06:49:08PM +0100, Polytropon wrote: > > On Sun, 23 Feb 2020 14:05:35 +0100, Jos Chrispijn wrote: > > > I read somewhere that using the rm command does not phsyically remove > > > the 'deleted' files when using the command in a terminal session. Can > > > you tell me how/where I can really remove these files (as per user > > > account or in general)? Thanks! > > > If you also want to remove the _data_ (read: the former file > > content), you need to overwrite the file's content with a > > random pattern or with zeros first. This can be done with > > the dd tool. There is also a port called "secure rm" (srm) > > that achieves the same "by overwriting, renaming, and > > truncating it before unlinking". You can find its manpage > > with further suggestions here: > > > > https://www.freebsd.org/cgi/man.cgi?query=srm > > > > However, this does not change things related to disk space > > becoming free. So when intending to simply remove files > > without any "recycle bin" nonsense, rm is the way to go. > > The thing about security is that often all you can do is raise the cost > of an attack. If the cost is high enough then you can often make an attacker > find a better use of their time. Fully agree. In 99% of the cases, it's not about "possible or impossible", but about "how much effort can you afford", as even data overwritten with random garbage and zeros _can_, given specific circumstances, be recovered. > Using forensics tools on a disk to recover a file that has been deleted > is pretty low cost. Still, I wouldn't expect the average street criminal > to be able to recover the files. The guy that broke into my house and > stole a jar of coins couldn't do it, for example. Using the _appropriate_ forensic tool requires a bit of experience, usually preceeded by reading, learning, and thinking, but yes, it is absolutely possible. I know this, because due to fat fingers I had to do recovery for accidentally deleted files more than once. ;-) > For example, SSD's will do wear leveling, and that means that a write to > a block at a particular offset will typically end up going to a different > physical block on the drive. The previous contents won't be available > to normal use, but tools no doubt exist that can recover the previous > block. A good example. Especially with SSDs, you cannot exactly predict _where_ a write operation will take place - will it be the same memory cells that previously contained the file, or will the controller choose different memory blocks and dynamically map them to the "original" blocks, as in "you told me to overwrite block 12345, I report back that I've overwritten block 12345, but I don't tell you that I actually chose block 987654 to be addressed block 12345". :-) > So, what's the threat you are trying to protect yourself from? _This_ question is the beginning of the search for the right(TM) tools. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...