#2881 closed defect

Magic-folder sets executable bit on all regular files(!) and overwrites existing filesystem permissions — at Initial Version

Reported by: cypher Owned by:
Priority: major Milestone: undecided
Component: code-frontend-magic-folder Version: 1.12.1
Keywords: magic-folder security Cc:
Launchpad Bug:

Description

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 (particularly on Windows where the current working directory is always prepended to PATH).

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. :)

Change History (0)

Note: See TracTickets for help on using tickets.