Magic-folder sets executable bit on all regular files(!) and overwrites existing filesystem permissions #2881

Closed
opened 2017-06-22 05:37:49 +00:00 by crwood · 2 comments

After placing a single file into a local magic-folder directory, a subsequent restart of the tahoe client will result in that file's permission bits being altered -- more specifically setting the executable bit and removing group/world permissions (as though every file were effectively sent through a chmod 700). As a demonstration:

dev ~ % cp cat.jpg Magic-Folder
dev ~ % ls -al Magic-Folder
total 116K
drwxr-xr-x  2 user user 4.0K Jun 21 14:48 .
drwxr-xr-x 57 user user 4.0K Jun 21 14:28 ..
-rw-r--r--  1 user user 107K Jun 21 14:48 cat.jpg
dev ~ % tahoe restart
STOPPING '/home/user/.tahoe'
process 2592 is dead
STARTING '/home/user/.tahoe'
starting node in '/home/user/.tahoe'
dev ~ % ls -al Magic-Folder
total 224K
drwxr-xr-x  2 user user 4.0K Jun 21 14:49 .
drwxr-xr-x 57 user user 4.0K Jun 21 14:28 ..
-rwx------  1 user user 107K Jun 21 14:48 cat.jpg
-rw-r--r--  1 user user 107K Jun 21 14:48 cat.jpg.backup

This is should not be standard behavior for a number of reasons, among them the broader design principle that an application should never alter a user's pre-existing data (including filesystem metadata) without at least some form of input or indication that it is doing so, as well as, more seriously, the myriad of security-related concerns that stem from this behavior.

Instead, all files placed into a magic-folder should retain their original permissions until changed by a user -- or, at least, at minimum, they should not "magically" become executable. :)

After placing a single file into a local magic-folder directory, a subsequent `restart` of the tahoe client will result in that file's permission bits being altered -- more specifically setting the executable bit and removing group/world permissions (as though every file were effectively sent through a `chmod 700`). As a demonstration: ``` dev ~ % cp cat.jpg Magic-Folder dev ~ % ls -al Magic-Folder total 116K drwxr-xr-x 2 user user 4.0K Jun 21 14:48 . drwxr-xr-x 57 user user 4.0K Jun 21 14:28 .. -rw-r--r-- 1 user user 107K Jun 21 14:48 cat.jpg dev ~ % tahoe restart STOPPING '/home/user/.tahoe' process 2592 is dead STARTING '/home/user/.tahoe' starting node in '/home/user/.tahoe' dev ~ % ls -al Magic-Folder total 224K drwxr-xr-x 2 user user 4.0K Jun 21 14:49 . drwxr-xr-x 57 user user 4.0K Jun 21 14:28 .. -rwx------ 1 user user 107K Jun 21 14:48 cat.jpg -rw-r--r-- 1 user user 107K Jun 21 14:48 cat.jpg.backup ``` This is should not be standard behavior for a number of reasons, among them the broader design principle that an application should never alter a user's pre-existing data (including filesystem metadata) without at least *some* form of input or indication that it is doing so, as well as, more seriously, the myriad of security-related concerns that stem from this behavior. Instead, all files placed into a magic-folder should retain their original permissions until changed by a user -- or, at least, at minimum, they should not "magically" become executable. :)
crwood added the
unknown
major
defect
1.12.1
labels 2017-06-22 05:37:49 +00:00
crwood added this to the undecided milestone 2017-06-22 05:37:49 +00:00
Owner
(https://github.com/tahoe-lafs/tahoe-lafs/pull/458)
Owner

This is fixed and merged to master; awaiting a release

This is fixed and merged to master; awaiting a release
crwood added
code-frontend-magic-folder
and removed
unknown
labels 2019-01-29 15:57:43 +00:00
meejah added the
fixed
label 2019-03-20 01:18:12 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#2881
No description provided.