*SensitiveFilePermissions fails on ntfs-3g mounted filesystems #347
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-12#347
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
To share my files between Windows and Linux, my ~/.config/PyBitmessage is a symlink to the filepath on Windows. The NTFS partition is mounted using ntfs-3g. Due to this, the permissions cannot be changed. This causes an exception to be raised at startup.
Suggested fix: check the filesystem rather than the platform
Current workaround: comment out line 371 in shared.py
Thanks for reporting this. That's a (not extreme) corner case I obviously hadn't considered.
This is a little tricky. AFAIK, there is no prepackaged platform-independent way to identify the filesystem on which a file resides. The main problem is that stat/statfs/statvfs vary between POSIX platforms, and there aren't Python bindings that unify them as far as the filesystem type goes. The Right Way® might be to start contributing these bindings. But instead I'm tempted to check platform then blacklist NTFS from fixSensitiveFilePermissions using the output of
stat -f -c "%T"
, which I think should work for almost all linux folks. As far as I'm concerned, since I don't have a Mac with which I can experiment, OSX users will have to figure out their own solution should the need arise in their camp.Would you please tell me what output you get upon executing:
stat -f -c "%T" ~/.config/PyBitmessage/keys.dat
Notes:
fuseblk
is whatmount
returns, butntfs-3g
is the type specified in my/etc/fstab
. This is expected.NTFS has a complete different permission system anyway. If you have formatted an NTFS Drive correctly (aka. not manually messed with the permissions) a File usually inherits permissions from its directory. I advise to put the keys.dat in a folder, that is inside your %USERPROFILE% Directory. Then only you and administrators have accesss.
Hi AyrA, we understand very well that NTFS has a different permission system. That is precisely the source of the problem. nimdahk is having trouble because, for dual-boot reasons, their keys.dat resides on an NTFS filesystem mounted on a Linux system.
Why do we need to change permissions at all? Aren't the permissions in the users home directory set correctly by default?
If we remove the read-other permission, it protects the user's private keys.
But why are others allowed to read the file in your personal profile in the first place? It kinda negates the purpose of having it if others can just read your files anyway per default.
@AyrA Permissions are set "correctly" to the (customizeable) default, which is usually 633 (i.e. owner read/write, group read, other read). But that is not "correct" for key files. It is imperative that sensitive files be created under a more restrictive "umask" that prevents files from ever letting group members or other users get a file handle. http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html
Security is not the purpose of a home directory. In fact, there is no one purpose. It all depends on use and configuration.
I don't know why we need to fix an issue, that is obviously accepted in the Linux world. (Not having a private location for my files would actually be an instant reason to switch OS if I weren't using windows already). Instead we should possibly just implement encryption and decryption for files, because an admin can take ownership of your files anyway. We can encrypt and decrypt messages in bitmessage, so doing the same with a file shouldn't be any harder: http://eli.thegreenplace.net/2010/06/25/aes-encryption-of-files-in-python-with-pycrypto/
Yes, root can take ownership of your files. But they also can do anything they bloody want ... like directly access decrypted keys in-memory. If you don't trust root, you have much bigger problems. Yes, encryption is lovely. But that is no replacement for correctly using the POSIX permission system in the first place.
Not having a private location for my files would be an instant reason for me to, you know, make one. Or change the default umask. BFD.
What in the world do you mean? Private from whom?
At the very least, popular Linux install disks include an option to fix that second point automatically.
Oh, yeah, I forgot to answer this. It's because previous versions of this software failed to umask sensitive files appropriately. That's all.
Anyway, @nimdahk, there are two solutions that I think are reasonable in different ways:
For one thing, we have write support now...
I think we should err on the side of caution. That is, raise when non-fuseblk, error (but no raise) when fuseblk, and preferably add a warning to the GUI when fuseblk (with some guid for googling).
This fixes the problem in the only known-to-currently-exist case (mine) without putting others at risk.
Alternatively, just replace the raise with a big
print
statement and a pause before returning, followed by a warning in the GUI (status bar, messsage box...) if the GUI is actually opened.Hey @nimdahk, would you mind double-checking this fix for me?
👍 Works great, thanks. Hurray for symlinks!
Resolved by pull request #378