Opened at 2017-06-22T05:37:49Z
Last modified at 2019-03-20T01:18:12Z
#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. :)