WinSCPでsftp,scp時に暗黙のumask

WinSCPでsftp、scp経由でファイルをアップロードした際、想定しないパーミッションになっていました。
暗黙的なパーミッション設定(umask相当)が適用されるようです。
本記事では、このWinSCPでsftp、scpを使用した際の暗黙的なパーミッション設定についてまとめます。

まずWinSCPのデフォルト設定における動作について記載し、その後、ログの確認結果や、関連する設定、マニュアルの説明について触れます。

本記事の目的

• WinSCPでsftp、scpを使用した際の暗黙的なパーミッション設定動作を把握する

基本

前提

対象はWinSCP(本記事の作成時点で5.21)です。
sftp,scpのアクセス先サーバは、一般的なLinux等の想定です。

WinSCPでsftp、scpを使用した際の暗黙的なパーミッション設定

確認したところ、アップロードしたファイルのパーミッションは、WinSCP固有の暗黙的なパーミッション設定と、サーバ側のumask設定のビット和により決まるようです。

※サーバ側のumask設定
そのサーバにsftp、scpでログインした際にサーバ内の設定(/etc/profileや/etc/bashrc等)に従い適用されるumaskのことを、本記事では”サーバ側のumask設定”と呼ぶことにします。

サーバ側のumask設定の詳細については、umaskを徹底的に統一(ssh,sftp,scp,sudo,su)にまとめてあります。

sftp経由のファイルアップロード時

サーバ側のumask設定と、暗黙的なumask(“0111”)とのビット和が適用されるようです。

例：サーバ側のumask設定が”0007″であった場合、アップロードしたファイルには”0111″とのビット和であるumask”0117″相当が適用され、パーミッション”0660″になります。

ちょうど実行権(x)がクリアされる動作です。
安全上の配慮かもしれません。

scp経由のファイルアップロード時

サーバ側の”umask”設定と、暗黙的なumask(“0133”)とのビット和が適用されるようです。

例：サーバ側のumask設定が”0007″であった場合、アップロードしたファイルには”0133″とのビット和であるumask”0137″相当が適用された結果、パーミッション”0640″になります。

ちょうど実行権(x)と、自分以外(g,o)向けの書込権(w)がクリアされる動作です。
同じく、安全上の配慮かもしれません。

ディレクトリのアップロード時

ディレクトリのアップロードの際にはこのような暗黙的なパーミッション設定は無さそうです。

詳細

ログの確認

sftp経由のファイルアップロード時

OpenSSHのデバッグログを有効にして、ログを確認してみます。
※サーバ側のumask設定は”0000″にしてあります。

WinSCPにて、sftp経由でファイルをアップロードした際のログが以下です。

sftp-server[xxxxx]: open "/home/user/file" flags WRITE,CREATE,TRUNCATE mode 0666

発行されたopenコマンドの引数に”mode 0666″があることが分かります。
実際に、アップロードされた後のファイルのパーミッションは0666です。

比較のため、Linux(OpenSSHのクライアント機能)にて、sftp経由でファイルをアップロードした際のログが以下です。

sftp-server[xxxxx]: open "/home/user/file" flags WRITE,CREATE,TRUNCATE mode 0777

こちらは、”mode 0777″になっています。
実際に、アップロードされた後のファイルのパーミッションは0777です。

上記より、WinSCPのsftpでは、暗黙的に”0111″のumask相当の設定が適用されていることが分かります。

scp経由のファイルアップロード時

OpenSSHのサーバ側でscp時の詳細ログを残す方法が不明だったので、クライアント側(WinSCPやscpコマンド)で詳細ログを有効にして、ログを確認してみます。
※サーバ側のumask設定は”0000″にしてあります。

WinSCPにて、scp経由でファイルをアップロードした際のログが以下です。

(WinSCPのデバッグログで取得されたログ)
> YYYY-MM-DD HH:MM:SS.xxx [Background 1] C0644 1 scp2

“C0644″から、ファイルがパーミッション0644でコピーされていると推察できます。
実際に、アップロードされた後のファイルのパーミッションは0644です。

比較のため、Linux(OpenSSHのクライアント機能)にて、scp経由でファイルをアップロードした際のログが以下です。

(scp -vで表示された詳細ログ)
Sending file modes: C0777 6 file3
Sink: C0777 6 file3

“C0777″になっています。

上記より、WinSCPのscpでは、暗黙的に”0133″のumask相当の設定が適用されていることが分かります。

scpのログ形式

scpのログについて、”C0777″や、”Sink”といった記載に関し、正式なマニュアルらしきものをうまく見つけられませんでした。

ただ以下の記事が参考になったのでURIと、要点の引用をしておきます。

• How the SCP protocol works(Oracle社の記事)
  以下の部分がログの見方の参考になります。

The source mode
The protocol is a mixture of text and binary data that form protocol messages. For example, when the regular file is about to be sent (= source mode), the type of the message, mode, length and filename are provided in plain text, followed by a new line. The file data itself follows; more on this later. The message can look like this:
C0644 299 group
There might be more protocol text messages before the binary data transfer actually begins. The scp in source mode (= data producer) always waits for a reply before the next protocol line is sent. After the last protocol message was sent, the producer sends a zero byte to notify scp in sink mode about beginning of the actual data transfer. A confirmation zero byte is sent by the sink mode scp process after the last byte of a file was read on the other side.
The sink mode
Every message and every finished file data transfer from the provider must be confirmed by the scp process that runs in a sink mode (= data consumer). The consumer can reply in 3 different messages; binary 0 (OK), 1 (warning) or 2 (fatal error; will end the connection). Messages 1 and 2 can be followed by a text message to be printed on the other side, followed by a new line character. The new line character is mandatory whether the text is empty or not.
List of protocol messages
Cmmmm <length> <filename>
a single file copy, mmmmm is mode. Example: C0644 299 group
Dmmmm <length> <dirname>
start of recursive directory copy. Length is ignored but must be present. Example: D0755 0 docs
E
end of directory (D-E pairs can be nested; that's why we can copy recursively)
T<mtime> 0 <atime> 0
modification and access times when -p options is used (I guess you know why it doesn't make sense to transfer ctime). Times are in seconds, since 00:00:00 UTC, Jan. 1, 1970. Two zeroes are present there in case there is any need to use microseconds in the future. This message was not present in original rcp implementation. Example: T1183828267 0 1183828267 0
After the messages the raw data is transfered. The consumer reads exactly that much data as specified in the length field. D and T message must be specified before any other messages. This is because otherwise it couldn't be clear whether those lines are part of the protocol or part of the data transfer. From the way how the protocol works we can induce that:
after C message the data is expected (unless the file is empty)
after D message either C or E is expected. This means that it's correct to copy an empty directory providing that user used -r option.

もう1つ、以下の記事も参考になりました。

• Why am I getting a “Sink” error when using an SCP command?(StackExchange)

関連記事(シェル、umask等)

• ログインシェル、インタラクティブシェルの見分け方(bash)
• suやsudo時のログインシェル、インタラクティブシェル
• umaskを徹底的に統一(ssh,sftp,scp,sudo,su)
• WinSCPでsftp,scp時に暗黙のumask
• ssh,sftp,scp時のログインシェル、インタラクティブシェル