Set stricter directory permissions

[vu3rdd]

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]

We've had some discussion about file permission bits in the past here: #33 (comment).

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.

[Jacalz]

I think this is a good idea, albeit with slightly higher permission bits set. Even if umask decreases the permissions, we would still be (at least from the example in the other PR mentioned) getting higher permissions than what probably is necessary.

[Jacalz]

Gosec suggests 0750 as that means read/write/execute for user and read/execute for group and no permissions for other. I think that might make more sense.

[vu3rdd]

The reason for choosing 0700 was that since this is a program that is a very privacy oriented file transfer program, it would be prudent choose a more "paranoid" default. For instance, if a recipient got very sensitive files and didn't want another user to access it. As a program, we guarantee such a behaviour instead of relying on the operating system.

[Jacalz]

I know but I think 0700 is too strict given that it doesn't include group permissions. Using 0750 will be almost just as good but without potential permission issues.

[vu3rdd]

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]

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.