[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2881: Magic-folder sets executable bit on all regular files(!) and overwrites existing filesystem permissions

[Tahoe-LAFS]

#2881: Magic-folder sets executable bit on all regular files(!) and overwrites
existing filesystem permissions
-------------------------+-----------------------------------
     Reporter:  cypher   |      Owner:
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  undecided
    Component:  unknown  |    Version:  1.12.1
   Resolution:           |   Keywords:  magic-folder security
Launchpad Bug:           |
-------------------------+-----------------------------------
Description changed by cypher:

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

New 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.

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

--

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2881#comment:2>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage