search

netheril96 / securefs

Filesystem in userspace (FUSE) with transparent authenticated encryption
Other
742 stars 63 forks source link

Version 1.0.0 does not print "wrong password" when unlocking with a wrong password and asked to to go background afterwards #177

Closed mhogomchungu closed 6 months ago

mhogomchungu commented 6 months ago

Output when unlocking with version 0.14.2 with a wrong password.

securefs m -b abc des
Enter password:
[Error] [0x7f8bfae6f480] [2024-04-22 15:30:28.675214892 UTC] [int securefs::commands_main(int, const char* const*):1682]    Invalid password and/or keyfile

Output when unlocking with version 1.0.0 using a wrong password

"securefs" "mount" "-b" "abc" "def" 
Enter password:
[Warning] [0x7f6ed62ea000] [2024-04-22 15:17:25.422639794 UTC] [void securefs::MountCommand::recreate_logger():829]    securefs is about to enter background without a log file. You won't be able to inspect what goes wrong. You can remount with option --log instead.

Well, you cant "remount" because securefs is not running in the background because the attempt to unlock failed.

I think the previous behavior is the correct one, securefs should go into background after a successful unlocking.

netheril96 commented 6 months ago

I can fix this, but then if securefs fails to mount for other reasons (lockfile already exists), you still need to query the log file to find out. The inherent problem is that to go into background, securefs needs to fork, but that makes some state inconsistent, so my current change is to fork as soon as possible.

netheril96 commented 6 months ago

I'm guessing that you are concerned about the change for interfacing with SiriKaili? I think it is easier not to ask securefs to go to background in that case.

mhogomchungu commented 6 months ago

SiriKali requires running in the foreground for Windows only and running in the background for other systems. Not going to change this behavior.

I have made changes and SiriKali now uses the log file with versions 1.0.0 or greater of securefs.

The log file does not seem to be geared towards users of securefs.

Parsing log output like below text as a way of knowing a volume was successfully unlocked seems a bit fragile.

[Info] [0x7f6d9f22b6c0] [2024-04-24 04:51:15.723905426 UTC] [auto securefs::FuseHighLevelOpsBase::build_ops(const securefs::FuseHighLevelOpsBase *, bool)::(anonymous class)::operator()(fuse_conn_info *) const:354]    Fuse operations initialized