search

psanford / wormhole-william

End-to-end encrypted file transfer. A magic wormhole CLI and API in Go (golang).
MIT License
1.07k stars 54 forks source link

Set stricter directory permissions #85

Open vu3rdd opened 2 years ago

vu3rdd commented 2 years ago

Directory transfer of the transit protocol use the zip format internally to transfer a bunch of files/directories from the sender to the recipient. The recipient, creates the destination directory and unzips the zip file to recreate the directory that was sent by the sender. This process is transparent to the user.

This PR address two issues:

  1. wormhole-william is using 0777 for directory permissions at the creation time. This seems excessive. I believe, this was discussed in the past, but I can't find the right issue at the moment. We set it to a stricter 0700.
  2. For a wormhole-william to wormhole-william transfer on Un*x based systems (macOS, GNU/Linux), the file permissions on the sender side are restored at the recipient side as well. Sender is already sending the permission bits in the attributes field of the zip file entry. These bits are restored upon receive.
psanford commented 2 years ago

We've had some discussion about file permission bits in the past here: https://github.com/psanford/wormhole-william/pull/33#issuecomment-792350206.

The current code sets the permission to 0777 so that we respect the user's umask. This allows users to set their permissions to be as restrictive or permissive as they are comfortable with. We likewise do the same thing implicitly with the creation of files in those directories.

I believe this matches the behavior of the python magic-wormhole implementation.

vu3rdd commented 2 years ago

The current code sets the permission to 0777 so that we respect the user's umask. This allows users to set their permissions to be as restrictive or permissive as they are comfortable with. We likewise do the same thing implicitly with the creation of files in those directories.

The reason for choosing 0700 is to have a more paranoid approach to privacy. I understand the idea of respecting user's umask. Since umask only makes the given permissions stricter, in my humble opinion, choosing a more secure default would not do any harm.

Jacalz commented 1 year ago

The current code sets the permission to 0777 so that we respect the user's umask. This allows users to set their permissions to be as restrictive or permissive as they are comfortable with. We likewise do the same thing implicitly with the creation of files in those directories.

The reason for choosing 0700 is to have a more paranoid approach to privacy. I understand the idea of respecting user's umask. Since umask only makes the given permissions stricter, in my humble opinion, choosing a more secure default would not do any harm.

It is better to have a sane default than an overly paranoid setting that might cause issues for users. I still think it would be a good middle ground to select 0750 and let umask handle stricter permissions for those that want stricter permissions. This should avoid causing issues for users while still improving the permission security.