Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Shred is a secure delete utility that comes with RH Linux. The shred man page say that it does not work well with filesystem that use journaling.
I read a few articles in journaling. One of the article said "When metadata on the disk is updated, the updates are recorded in a separate area of the disk reserved for use as a journal. Filesystem transactions which complete have a commit record added to the journal, and only after the commit is safely on disk may the filesystem write the metadata back to its original location. Transactions are atomic because we can always either undo a transaction (throw away the new data in the journal) or redo it (copy the journal copy back to the original copy) after a crash, ac-cording to whether or not the journal contains a commit record for the transaction."
From this article, I dont quite understand why journaling is an issue in shred.
Journaling is meant for recovery when the system loss power abruptly. When this is the case, the file won't be overwritten properly which is true with or without journaling. It is not like journalling is going to "write data in a different data blocks" or something.
Many articles claimed that journaling is an issue in shred without any real in depth explanation.
Could any one please explain why journaling is an issue in secure delete?
A sample scenario would be nice!
Also, if journaling is indeed pose complication, then would this help at all:
mount -t ext3 -o data=writeback /dev/sda2 /jdisk
(Basically this mount the with the writeback mode for ext3).
I'm afraid I can't offer much in the way of technical details, but there was a related question a while back. I don't know if using the writeback option would help, but I guess you could probably mount the filesystem as ext2, do your secure deletions, then remount as ext3 again.