lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bug-220288-13602-3XrhovDMrJ@https.bugzilla.kernel.org/>
Date: Sat, 28 Jun 2025 08:47:06 +0000
From: bugzilla-daemon@...nel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 220288] A typo Leads to loss of all data on disk

https://bugzilla.kernel.org/show_bug.cgi?id=220288

--- Comment #2 from Martin Vahi (martin.vahi@...tf1.com) ---
Thank You for the answer. 
What regards to the line of thought that the behavior of fsck.ext4 is
just fine as long as it asks the user for the "yes" for modifications
then I think that it is a flawed line of thought, because from 
users point of view the fsck.ext4 is run  

    WHENEVER THE FILE SYSTEM DOES NOT MOUNT DUE TO DIRTY JOURNAL

and the end user will not start to do any "forensic analysis" to start
thinking, if some change that the fsck.ext4 wants to do is OK or not, specially
if it shows some kind of numbers as part of the question. From fsck.ext4 user's
point of view the
idea is very staightforward: 

    if (<partition does not mount due to dirty journal>){
       
func_run_the_fsck_ext4_and_it_better_do_its_job_without_any_mystic_number_scribble()
    }

and if some question about individual inodes does appear on screen, then just
press Yes to get that "nonsense" out of the way. If the text with the question
were "Are You sure that You asked the fsck.ext4 to modify the right partition,
because according to our suspicionns You made a  typo and may be You want to
consider running fsck.ext4 on '/dev/sdc1' in stead of '/dev/sdc'?", then the
end user has at least some meaningful text to think about before pushing the
y-button. But if the question is, as You describe, about some i-nodes, then
from user's perspective those questions are expected to be pretty much the same
for both,  correct "/dev/sdc1" and for the typo-infected "/dev/sdc", which
means that the question about some inodes does not convey the message to the
end user that there could be something wrong at the call to the fsck.ext4. 

Someone, who has self designed the fsck.ext4 may find the difference obvious,
but for the rest of us, me being part of "the rest of us", it is NOT obvious
that fsck.ext4 asks some questions about inodes if I have given device name in
stead of a  partition name to the fsck.ext4.

To put it in another words, it is not enough for a commonly used tool like the
fsck.ext4 to work correctly according to notes at some deep documentation, but
it should actually detect probable user mistakes and draw user's attention to
the possible end user mistake by using a message that even that kind of an end
user, who has  NOT read loads of documentation and NOT intimately worked with
fsck.ext4, can understand clearly. A messaging format that it asks something
about inodes in one  case and does not  ask that in another case is not clear 
enough messaging format to make the user suspicious enough about possible user
mistake.

Thank You for the anwer and thank You for reading my comment(s).

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ