朝から昼寝

ITや家計、身近なことの整理

[お知らせ]
当サイトは、2024年1月1日に
新URL(happynap.net)に引っ越しました





このページの内容は、最新ではない場合がありますので、新URLをご確認ください。






当サイトには広告を含みます。"オススメ"として紹介している商品やサービスは、個人的にそう思えたものだけです。
共感、興味をもっていただけるものがあればご利用ください (広告掲載ポリシー)。

(図解)Google AdSense利用規約の秘密保持の条項

概要

ブログ等でGoogle AdSenseのことを扱う際に、記載してはいけない情報があるようです。
本記事では、Google AdSense利用規約の秘密保持の条項についてまとめます。

本記事の目的

  • Google AdSense利用規約の秘密保持の条項について理解する


目次

基本

前提

本記事は、2022年12月16日時点のAdSense オンライン利用規約(請求先住所:日本)(以降、"利用規約")について記載します。

本記事の作成時点では、第11条に秘密保持に関する記載がありますので、主にこれについてまとめます。

なお、本記事では触れませんが、利用規約には違反していなかったとしても、知的財産権等の侵害、公序良俗に反すること、その他適法でない行為に該当しないかについても注意が必要です。

また、本記事の図を含む内容は、私の解釈に基づいて作成したものです。Google社の意図するものとは異なる場合があります。

図解

まず、なんとなく利用規約にある文章を図にしてみます。

Google AdSense オンライン利用規約の”秘密保持”に関する記載
Google AdSense オンライン利用規約の”秘密保持”に関する記載

…視覚的に捉えやすくはなったと思います。

Google機密情報が開示不可、それ以外は開示可とされています。当たり前ですね。
※"開示"は、そのことを記載したブログ記事等をインターネットに公開する行為を含むものとして、本記事の話を進めます。

Google機密情報のうち、(b)については各サイトのGoogleアドセンスの実績データも含まれると解釈できます。よって、Googleアドセンスのレポート画面やそのデータをブログ等で公開してはいけないということになります。

ただし、支払総額に関しては開示可とされています。"Googleからアドセンスの収益○○円が振り込まれた"という事実は公開しても良いということになります。

詳細は後述します。

詳細

注意が要りそうな点について詳しく確認していきます。

Google機密情報(b)の詳細

記載内容

Google機密情報(a)~(d)のうち、上記で少し触れた(b)の項目です。

(b) 本サービスとの関係において広告媒体の実績に関連したクリックスルー率その他の統計
AdSense オンライン利用規約(請求先住所:日本)より

表現の比較のため、一応英語版の利用規約も確認します。

(b) click-through rates or other statistics relating to Property performance as pertaining to the Services
AdSense オンライン利用規約(請求先住所:アメリカ合衆国)より

各単語の解釈

(b)内の各単語は、以下のように解釈できます。

  • 本サービス = Googleアドセンス
  • 広告媒体 = Webサイト等、Googleアドセンスの広告を掲載する対象
  • クリックスルー率 = CTR (ページCTR = クリック数 / ページビュー数)
  • クリックスルー率その他の統計 = CTR、および、それ以外の統計

"クリックスルー率その他の統計"("click-through rates or other statistics")という表記は、広く捉えれば統計データ全般を指すものと解釈できます。
その場合、Googleアドセンスの管理画面に表示されるデータは全てGoogle機密情報に該当することになるでしょう。

逆に、"一部のデータのみ"に限定するような解釈ができるかを考えてみたところで、"統計"が何を指すのかという定義が見当たらないため明確な判断は難しいです。

そもそも"本サービスとの関係において広告媒体の実績に関連"するという条件なので、管理画面に表示されるデータは全て該当するという判断が自然でしょう。例えば、CTR以外に"推定収益額"や"クリック数"、"クリック単価(CPC)"等も該当します。

(余談)ちなみに、クリックスルー率=CTRであることが分かる日本語ヘルプが見当たらなかったので、そこは英語版ヘルプの"clickthrough rate (CTR)"という表現を参照しています。

画面キャプチャでなければ大丈夫?

管理画面のキャプチャでなく、データの数値部分だけを抜粋したものなら開示してよいか、という点についても考えてみます。

"統計"がGoogle機密情報であるという点を考慮すると、画面でなく数値データは"統計"の主たる要素そのものですから、やはりGoogle機密情報に該当するでしょう。

加工すれば大丈夫?

概数による表現("95クリック"を"約100クリック"とボカす)や、数値部分にモザイクを入れた画面キャプチャ(桁数は判別できる)等、色々と"加工"の仕方は考えられるかもしれません。

ただ、おおもとのデータが"本サービスとの関係において広告媒体の実績に関連したクリックスルー率その他の統計"に該当している点、また、どのような"加工"をすれば開示しても良い情報になるのかという定義が無い点から、"Google機密情報ではない"とは言い難いです。

Google機密情報(c)の詳細

以下の記載内容です。

(c) 本サービスにおける非公開のベータ版機能または体験版機能の存在、それに関する情報、またはその規約
AdSense オンライン利用規約(請求先住所:日本)より

これは記載のとおりですね。

新しい機能等に関する記事の開示は、Google社もしくはGoogle社に認められたものによって公開されるまで開示してはいけません。

Google機密情報に含まれない"お客様の責によらず公知となった情報"

Google機密情報に含まれないものとして、"お客様の責によらず公知となった情報"(英語版では"that becomes public through no fault of yours")が挙げられています。

このような記載がなぜ必要なのか不思議に思ったので、記載しておきます。

例えば、以下のような情報も"お客様の責によらず公知となった情報"に該当するかどうかです。

  • 事故的に漏れてしまったGoogle機密情報
  • 誰かがこの利用規約に反して開示してしまったGoogle機密情報
    (意図的かどうかに関わらず結果的にリークしたもの)

これらを"お客様の責によらず公知となった情報"に該当するものとして扱ってしまうと、例えば、"あのブログに載ってたCTR"とか"あの動画で言ってたクリック単価"がGoogle機密情報ではなくなり、(この利用規約としては)開示しても良いことになってしまいます。
※例なので該当のブログや動画の著作権等について考慮していません。

もちろん、そのような扱いを認めてしまうと、せっかく定義したGoogle機密情報(a)~(d)が蔑ろになってしまうので、認められないと思うのですが、利用規約からはそれが読み取れません。

また逆に、認めない場合、そもそもどのようなケースを想定してこの"お客様の責によらず公知となった情報"をわざわざ挙げているのかが不明でした。

引用

利用規約の該当箇所を引用しておきます。

  1. 秘密保持
    お客様は、当社の事前の書面による承諾なく Google 機密情報を開示しないことに合意するものとします。「Google 機密情報」には、(a)本サービスに関連する一切の Google のソフトウェア、技術および文書、(b)本サービスとの関係において広告媒体の実績に関連したクリックスルー率その他の統計、(c)本サービスにおける非公開のベータ版機能または体験版機能の存在、それに関する情報、またはその規約ならびに(d)Google により提供されるその他の情報であって、機密であると指定されるか、それが提示される状況において通常機密とみなされるものが含まれます。Google 機密情報には、お客様による本サービスの利用より前にお客様にとって既知であった情報、お客様の責によらず公知となった情報、お客様が独自に開発した情報、または第三者によりお客様に適法に与えられた情報は、含まれないものとします。本第 11 条にかかわらず、お客様は、自らによる本サービスの利用によりもたらされた Google による支払総額を正確に開示することができます。
    AdSense オンライン利用規約(請求先住所:日本)より

まとめ

ブログ等でGoogle AdSenseのことを扱う際に注意すべき、Google AdSense利用規約内の秘密保持に関する条項について確認してきました。

利用規約の違反をGoogle社が積極的に取り締まっている風には見えませんが…ただ世の中のサービスを使う上で、"利用規約"は重要なものなので、きちんと理解できるよう心がけたいです。

参考

  • 本記事は、Icons8のアイコンを使用しています(Icons by Icons8)。

ssh,sftp,scp時のログインシェル、インタラクティブシェル

概要

スクリプトやツールを使用する際、ログインシェルか、インタラクティブシェルかを考慮しないといけないことがあります。
本記事では、sshsftpscpでサーバにログインした際に起動されるシェルがログインシェルかどうか、インタラクティブシェルかどうかについてまとめます。

本記事の目的

  • sshsftpscpを実行した際に起動されるシェルがログインシェルかどうか、インタラクティブシェルかどうかを確認する


目次

基本

前提

対象はbash(GNU Bash)、ssh、sftp、scpあたりのコマンドと、WinSCPです。

記載されている動作確認結果はRHEL8系のものです。別のOSやLinuxディストリビューションについては、コマンド自体の違いは無いか、あっても少ないはずですが、関連するStartup Files(profileやbashrc等)の構成が違うことより結果的に異なる動作になる場合があります。

sshsftpscp時のログインシェル、インタラクティブシェル

以下のようになります。

一般的なssh関連アクセスと、WinSCPによるアクセスに分けて記載します。

一般的なssh関連アクセス

コマンド ログインシェル インタラクティブシェル
ssh
sftp
scp

●:該当

"一般的なssh,sftp,scp"と記載したのは、OpenSSHのクライアント機能や、sshについてはWindows上のターミナルソフト(PuTTYTeraterm)を想定したものです。 一方で、WinSCPのsftp、scpによるアクセスは少し異なるため、後述します。

WinSCPによるsftp、scpアクセス

コマンド ログインシェル インタラクティブシェル
sftp
scp(※1)

●:該当

(※1)WinSCPのシェル設定が"デフォルト"の場合です。

WinSCPの場合は、内部的にはscp時にログインシェルが起動します。

詳細

sftp,scp時のログインシェル、インタラクティブシェルの確認方法

sftpscp経由のアクセス時に、ログインシェル、インタラクティブシェルかどうかを確認する方法をメモしておきます。
※これらのアクセス時には、対話的なシェル環境が無いので以下のような方法を使います。

/etc/profile/etc/bashrc、それぞれの冒頭に以下を追記します。

shopt > ~/shopt.txt
echo $- > ~/if_intr.txt

上記設定により、次回以降のログイン時にそれぞれのファイルが読み込まれると、そのユーザのホームディレクトリ配下にshoptecho $-の結果が記録されますので、そこからログインシェル、インタラクティブシェルかどうかを確認できます。
読み込まれなかった場合は、ファイルが作成されません。

shoptについては、ログインシェルかどうかの確認だけであればshopt -q login_shellだけでも良いです。 shopt以外に、echo $0 > ~/d0.txtのように$0の内容を記録することもできます。

shoptecho $-の結果の見方については、別記事でログインシェル、インタラクティブシェルの見分け方(bash)にまとめてあります。

sftp時の確認例

sftpでのアクセス時は、以下のようになります。
(WinSCPかどうかに関わらず同じ結果)

  • shoptの結果
    "login_shell off" ※非ログインシェル

  • echo $-の結果
    "hBc" ※"i"が無いので非インタラクティブ

  • (参考)echo $0の結果
    "bash" ※bashは起動されている

scp時の確認例

scpでのアクセス時は、以下のようになります(環境と設定により違います)。

scpWinSCPの場合(シェル設定が"デフォルト"時)

前述の表のとおりです。

  • shoptの結果
    "login_shell on" ※ログインシェル

  • echo $-の結果
    "hB" ※"i"が無いので非インタラクティブ

  • (参考)echo $0の結果
    "-bash" ※argv[0]の先頭が"-"なのでログインシェル

scpWinSCPの場合(シェル設定が"/bin/bash"時)

これは前述の表にはないパターンです。非ログインシェルになります。

  • shoptの結果
    "login_shell off" ※非ログインシェル

  • echo $-の結果
    "hBc" ※"i"が無いので非インタラクティブ

  • (参考)echo $0の結果
    "bash" ※bashは起動されている

scpWinSCP以外の場合(Linuxscpコマンド等)

前述の表のとおりです。

  • shoptの結果
    "login_shell off" ※非ログインシェル

  • echo $-の結果
    "hBc" ※"i"が無いので非インタラクティブ

  • (参考)echo $0の結果
    "bash" ※bashは起動されている

WinSCP内のSCP/シェルの設定等々

ここからはほぼ余談です。

WinSCPの設定画面には以下のようにSCP/シェルに関する設定画面があります。

基本的に"デフォルト"で問題がありませんが、前述のように適用されるシェル環境に違いがあります。

`SCP/シェル`の設定
`SCP/シェル`の設定

WinSCP開発元の関連マニュアルです。

The options are mainly used when working with SCP protocol.

Use the Shell option to specify what shell WinSCP will use. The bash shell is recommended for working with WinSCP.
The SCP/Shell Page (Advanced Site Settings dialog)

より詳細は以下です。

As a GUI client, WinSCP requires that the server provide more functionality than just SCP (which can only transfer files).
SCP (Secure Copy Protocol)
SCP Requirements
Other Options

WinSCSPでのscp使用時には、以下のようにシェルのコマンドを実行することもできます。

Running a Shell command

scpよりsftpを使用するケースがほとんどかと思いますが。

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

まだ使える?手元にあるWindows8.1 PC

概要

2023年1月10日にWindows8.1のサポートが終了します。
本記事では、そんなWindows 8.1のPCをまだまだ使えるようにするためにできることをまとめます。
※私の実経験に基づく内容ですが、記載内容について保証するものではありません。ご了承願います。

経緯として、2014年購入の私物PCがWindows8.1のままだったのでWindows10にアップグレードした際に調べたものです(Windows11のシステム要件は満たせませんでした…)。

※Windows 8.1のサポートが2023年1月10日に終了します。
Windows 8.1のサポートが2023年1月10日に終了します。

本記事の目的

  • 手元にある古いパソコンがまだ使えるかを考える


目次

基本

まだ使えるようにしたWindows 8.1 PC

2014年購入の以下のノートPCです。
製品説明ページ
※"カスタムメイドモデル"の"Windows 8.1 "を選択した際に表示されるスペック

  • メーカー:富士通
  • 品名: LIFEBOOK UHシリーズ WU1/M (2013年10月発表モデル)
  • 型名: FMVWMU1N57
  • CPU: Intel Core i5-4200U(第4世代,Haswell)
  • チップセット: メーカー独自?(FJNB27E)
  • メモリ: 10GB (標準のメモリ6GBから交換により増量済)
  • ストレージ: 1TB SSD (標準のHDD 500GBから交換済)
  • GPU: CPU内蔵(Intel HD Graphics 4400)
  • OS: Windows 10 Home (標準のWindows 8.1 Homeから再セットアップ済)

ブログ作業用PCなのですが、まだまだ使えるスペックになりました。

スペックを見直した点は、上記の赤字部分です。

まとめると以下です。

  • メモリ増設
  • HDD→SSD交換
  • Windows 10へのアップグレード(再セットアップ)

順に記載していきます。

メモリ増設

6GBだと少ないので10GBまで増やしました。

もともと搭載されていた4GBメモリを、新たに購入した8GBメモリに交換しました。 オンボードで2GBなので、合計2+8=10GBです。

私が増設用に購入したメモリは以下です。

そのPCに搭載可能な規格で選べばOKです。

今回のPCでは、"DDR3L SDRAM PC3L-12800"、形状は"SO-DIMM"です。

※SO-DIMMスロットが"交換不可"と記載されていますが、交換はできました。

なお、ノートPCの中は狭いので、筐体内に収まるサイズであることは事前に確認した方が良いでしょう。

HDD→SSD交換

500GB HDDだととにかく遅いので、SSDにしました(重要)。
古いPCでも、SSDにさえしておけば、なんとかなる気がします。

もともと搭載されていた500GB HDDを、新たに購入した1TBのSSDに交換しました。

そのPCに搭載可能な規格で選べばOKです。

今回のPCでは、Serial ATA 6Gbpsに対応しているので、Serial ATA(SATA)の"SATA Ⅲ(SATA600)"です。
(ちなみに1世代前のSATA Ⅱだと3Gbpsです(SATA300))

ありがたいことにバックアップソフト(Acronis True Image WD Edition)が付属しているので、HDD内のデータをSSDに簡単にコピーできます。OSの再セットアップなどは不要です。

注意点として、HDDからSSDにデータをコピーする際に使用するケーブルの用意が必要です。 私は以下を購入しました。

Windows 10へのアップグレード(再セットアップ)

上記のメモリ増設とSSD交換をして、しばらくWindows 8.1のまま使っていたのですが、サポート終了も近づいてきたのでアップグレードすることにしました(調べた結果、再セットアップすることにしました)。

購入したライセンスは、Windows10にダウングレード可能なWindows11のDSP版ライセンス、12,400円(Amazon)です。再セットアップした際の記事は以下です。

happy-nap.hatenablog.com

やっぱり面倒な場合は、、、

ここまで読んで頂き、PCのスペック見直しや再セットアップ等に手間をかけたくないと思われた方は、PCの買い直しを検討されても良いでしょう。

「これはアリ」と思ったノートPC

以下の記事で、個人的に「これはアリ」と思ったノートPCについて随時更新しています。

happy-nap.hatenablog.com

売れ筋ランキング等

💻ノートPC ランキング(Amazon)
💻Amazon整備済み品 ランキング(Amazon)
↑"Amazon整備済み品"は保証付きの再生品で、評価も比較的良さそうです。
💻ノートPC週間ランキング(楽天市場)
💻約10,000円~Windows10 PC(Amazon)

中古PCはシステム要件に注意が要るため、迷う場合は新品が良いです。
以下の記事でWindows11の中古PCを選ぶ際の注意点についてまとめてあります。

happy-nap.hatenablog.com

詳細

ライセンス購入やDSP版ライセンスの詳細

補足として、Windowsのライセンス購入が必要と判断した経緯や、DSP版ライセンスについての詳細は、以下にまとめてあります。

happy-nap.hatenablog.com

happy-nap.hatenablog.com

関連記事

(下にいくほど技術寄りの内容です)

happy-nap.hatenablog.com

WinSCPでsftp,scp時に暗黙のumask

概要

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

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

本記事の目的


目次

基本

前提

対象は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と、要点の引用をしておきます。

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つ、以下の記事も参考になりました。

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

umaskを徹底的に統一(ssh,sftp,scp,sudo,su)

概要

サーバ上で作業する際のumask設定を統一したいことがあります。
ssh、sftp、scp、sudo、su等、多様なログインやユーザ切り替えを想定すると、たくさんの設定箇所を考慮する必要性があります。
本記事では、umask値を統一する方法についてまとめます。

本記事の目的

  • umask設定を統一する際のポイントを把握する


目次

基本

前提

対象OSはRHEL8系(CentOS、AlmaLinux、RockyLinux等)、シェルは主にbashです。

他のOS、ディストリビューション、シェルでは関連するStartup Files(profileやbashrc等)の構成が違えば、結果的に異なる動作になりますが、原理は同様です。

(本記事の内容は、なるべく確認した上で記載していますが、パターンが膨大なので全てが正確ではないかもしれません)

umaskの各設定箇所

Linux上のログインやシェル切り替えの際に適用される設定のうち、umaskに関するものを記載します。

/etc/login.defsUMASK

他の設定箇所より先に適用されるumask設定です(詳細は後述)。
先に適用されると言っても、その後、他の設定箇所によりumask設定を上書きされるケースがほとんどです。

よって、この/etc/login.defsUMASKの変更は、特定の意図が無い限りは意味が無いでしょう。

デフォルトでは以下のようになっています。

UMASK           022

/etc/pam.d/sshdpam_umask

sshd経由のログイン時に適用されるumask設定です(pam_umaskの詳細は後述)。

以下のように、/etc/pam.d/sshdpam_umask.soの行を追記することで設定されます(最終行への追加でOK)。

session optional pam_umask.so umask=0077

umaskの指定方法はいくつかありますが、上記のように行末にumask=オプションを指定するのがシンプルでしょう。

デフォルトでは、/etc/pam.d/sshdpam_umask.soは含まれていません。

/etc/ssh/sshd_configSubsystem sftp-u

sftp経由のログイン時に適用されるumask設定です。

以下のように、sftp設定の行末に-uオプションを指定します。

Subsystem       sftp    /usr/libexec/openssh/sftp-server -u 007

/etc/sudoersumask_override

sudoで指定したコマンド実行時に適用されるumask設定です。
(設定方法により動作が異なるので、詳細は後述します)

以下のように、Defaults umaskDefaults umask_overrideの行を追記します(最終行への追加でOK)。
※これはumask =で指定したumask設定で"上書き"する設定です。
※直接/etc/sudoersを編集せず、visudoを使用する方が良いです。

Defaults umask = 0077
Defaults umask_override

この設定は、sudo susudo su -実行時に起動されるシェルのumaskには影響しません。

/etc/profile

ログインシェル起動時(少なくともbashの場合)に適用されるumask設定です。

以下のように、uidが200以上の場合に適用される箇所を書き換えます。
※この手順は、内容をきちんと理解した上で実施する必要性があります。/etc/profileの直接編集自体は分かりやすいのですが、良いやり方ではないとされています(詳細は後述)。

if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
    #umask 002 ←コメントアウト
    umask 077 ←追記
else
    umask 022
fi
…

(補足)rootのみに適用されるumask設定を追加したい場合は、上記のif文の後に以下を追記します。

if [ $UID -eq 0 ]; then
    umask 077
fi

ログインシェル、インタラクティブシェル等のシェル種別に応じた条件分岐(if文)については後述します。

/etc/bashrc

bashかつ非ログインシェル起動時に適用されるumask設定です。

umaskの設定に関しては上記の/etc/profileと同様なので省略します。

~/配下

本記事ではシステム全体(System wide)の設定について記載するので、ユーザごとの設定については省略します。

~/.profile~/.bashrcといったファイルのことです。

基本的には、システム全体の設定ファイルが読み込まれた後に、これらのファイルが読み込まれます。

アクセス方法ごとのumask設定まとめ

前述の各設定箇所が、アクセス方法ごとに適用されるかどうかを表にまとめます。

一般的なssh関連アクセス

下表は、一般的なssh,sftp,scpによるアクセス時に適用される設定です。
設定ファイル自体が読み込まれるかどうかではなく、umask設定に影響するかどうかの観点でまとめたものです。

適用順は、左が先、右に向かって後です(先→後)。

/etc/login.defs /etc/pam.d/sshd sshd_config /etc/profile /etc/bashrc
ssh
sftp
scp

●:適用される

"一般的なssh,sftp,scp"と記載したのは、OpenSSHのクライアント機能や、sshについてはWindows上のターミナルソフト(PuTTYTeraterm)を想定したものです。
一方で、WinSCPのsftp、scpによるアクセスは少し異なるため、後述します。

WinSCPによるsftp、scpアクセス

下表は、WinSCPによるsftp、scpアクセス時に適用される設定です。
設定ファイル自体が読み込まれるかどうかではなく、umask設定に影響するかどうかの観点でまとめたものです。

適用順は、左が先、右に向かって後です(先→後)。

/etc/login.defs /etc/pam.d/sshd sshd_config /etc/profile /etc/bashrc 暗黙値
sftp
●(※2)
scp
●(※1)
●(※2)

●:適用される
(※1)WinSCPのscp時のシェル設定が"デフォルト"の場合、ログインシェルが起動するようです(詳細は別記事のssh,sftp,scp時のログインシェル、インタラクティブシェルにまとめてあります)。
(※2)おそらくWinSCP固有の仕様で、sftp経由のファイルアップロードの際には暗黙的な0111(実行権クリア)とのビット和のumaskになるようです。scp経由のファイルアップロードの際には0133(0022+実行権クリア)とのビット和のumaskになるようです。ディレクトリのアップロードの際にはこのような暗黙的な設定は無さそうです(詳細は別記事のWinSCPでsftp,scp時に暗黙のumaskにまとめてあります)。

susudoの実行時

下表は、susudo実行時に適用される設定です。
設定ファイル自体が読み込まれるかどうかではなく、umask設定に影響するかどうかの観点でまとめたものです。

主にrootのシェルへの切り替え(-u無し)を想定しています。

適用順は、左が先、右に向かって後です(先→後)。

/etc/login.defs /etc/sudoers /etc/profile /etc/bashrc
su
su -
sudo -s
●(※2)
sudo -i
sudo (コマンド)(※1)
sudo su
(※3)
sudo su -
(※3)
sudo bash

●:適用される
(※1)シェル起動やsu以外のコマンドのことです。
(※2)起動されるシェルはsudo実行時のSHELL環境変数によります。
(※3)/etc/sudoersのumask設定は、sudo susudo su -は、新たに起動されるシェルには反映されません。

上記仕様をスッキリ理解するには、前提としてsusudo実行時のログインシェル、インタラクティブシェルについて把握する必要性があります。以下に補足します。

(別のまとめ方)シェル種別ごとの適用される設定

以下は前提となる関連記事です。

アクセス方法でなく、ログインシェル、インタラクティブシェルの観点でまとめた場合は以下のようになります。
設定ファイル自体が読み込まれるかどうかではなく、umask設定に影響するかどうかの観点でまとめたものです。

/etc/profile /etc/bashrc
ログインシェルかつ
インタラクティブシェル
ログインシェルかつ
インタラクティブシェル
非ログインシェル
インタラクティブシェル
非ログインシェル
&非インタラクティブシェル
シェル起動無し

●:適用される

/etc/bashrcには、if ! shopt -q login_shell ; thenというif文があり、非ログインシェルの場合にのみ以降のumask設定を含む処理が実行されるようになっています。

ちなみに、本記事ではbashについて記載していますが、zshでは/etc/zprofileから/etc/profileがsourceされるようです。

umaskの統一の仕方

上記にて、umaskの各設定箇所と、アクセス方法ごとに適用されるumask設定についてまとめました。

これらを参考に、想定されるアクセス方法に応じて設定すれば、umaskを統一できることになります。

例えば、sshログインとsudo -iしか行わないのであれば、/etc/pam.d/sshd/etc/sudoersの設定くらいで済みます(もしくは/etc/profileの設定のみ)。

詳細

/etc/login.defsUMASKとpam_umask

ざっくり言うと、PAM経由の認証時には/etc/login.defsUMASKが適用されているようです。

ただ、PAMの後の処理で他の設定箇所によりumask設定が上書きされるケースがほとんどです。

/etc/login.defsは、shadow-utils(shadowパスワード機能)によって使用されるファイルのようです。

現在は、shadowパスワード機能によって提供されていた機能の大部分はPAMによって処理されていますが、PAM経由で/etc/login.defsが使用されるケースがあります。

/etc/login.defsUMASKは以下のように記載されています。

# Default initial "umask" value used by login(1) on non-PAM enabled systems.
# Default "umask" value for pam_umask(8) on PAM enabled systems.
# UMASK is also used by useradd(8) and newusers(8) to set the mode for new
# home directories if HOME_MODE is not set.
# 022 is the default value, but 027, or even 077, could be considered
# for increased privacy. There is no One True Answer here: each sysadmin
# must make up their mind.
UMASK           022

PAMにおいて、pam_umaskはこのUMASKの値をもとにumask設定を行います。

具体的には、/etc/pam.d/postloginpam_umaskが定義されています。

# grep -i umask /etc/pam.d/*
/etc/pam.d/postlogin:session     optional                   pam_umask.so silent

PAMのpostlogin設定は、man postloginによると、system-authの後など、広範に適用されるようです。

DESCRIPTION
       The  purpose  of this PAM configuration file is to provide a common place for all PAM modules which should be
       called after the stack configured in system-auth or the other common PAM configuration files.

       The postlogin configuration file is included from all individual service  configuration  files  that  provide
       login service with shell or file access.

NOTES
       The modules in the postlogin configuration file are executed regardless of the success or failure of the mod‐
       ules in the system-auth configuration file.

pam_umaskは、以下の優先順でumaskの値を取得します(man pam_umaskより)。

       The PAM module tries to get the umask value from the following places in the following order:
       ・   umask= entry in the user's GECOS field
       ・   umask= argument
       ・   UMASK entry from /etc/login.defs
       ・   UMASK= entry from /etc/default/login

/etc/profile/etc/bashrcの直接編集が良いやり方ではない理由

/etc/profileの冒頭に説明がある通りです(/etc/bashrcも同様)。

(RHEL8系の/etc/profileの冒頭より抜粋)
# It's NOT a good idea to change this file unless you know what you
# are doing. It's much better to create a custom.sh shell script in
# /etc/profile.d/ to make custom changes to your environment, as this
# will prevent the need for merging in future updates.

/etc/profileを直接編集する代わりに、/etc/profile.d/umask-cust.shのようなファイルを作成し、その中に目的のumask設定のみを記載する方が設定ファイルの構成としてはキレイです。
将来的に、アップデートにより/etc/profileが更新された際、マージが容易になります。何よりレベルダウンの発生を回避しやすくなります。

一方で、サーバ管理上は/etc/profile.d/umask-cust.shを作成したということをきちんと構成管理しなければならないという手間もあります。知らずに他の設定を近辺に加えていくと、逆に混乱を招いてしまうでしょう。

(諸説)結局/etc/profileを直接編集した方が分かりやすいのでは

実際に/etc/profileがアップデートにより上書きされた、という話を私は知らないので、/etc/profileを直接編集しても良いのではと思っています。

諸説あることの例として、RHELの公式説明ですら、バージョンごとにかなり違っているという点も含めて記載します。

まずRHEL6向けの古いKBです。
/etc/profileの直接編集を回避するよう書かれています。

まず、/etc ディレクトリーのファイルはすべてのユーザーに対するグローバルな設定ですが、それを変更するのはできるだけ回避する必要があります。グローバル設定を修正する必要がある場合は /etc/profile.d を使用することができます。これにより、パッケージをアップグレードした時に変更箇所が元に戻るのを回避できます。
RHEL におけるシェルプロファイル(RHEL6向けのKB)

次にRHEL8向けのマニュアルです。
なんと/etc/profileを直接編集する手順が紹介されています。

/etc/profile ファイルを変更して、root ユーザーのデフォルトの bash umask を変更できます。
26.6. ログインシェルのデフォルト umask の変更

次にRHEL9向けのマニュアルです。
なぜか/etc/login.defsを編集する手順に変わっています(これはこれで意図が不明)。

/etc/login.defs ファイルを変更して、root ユーザーのデフォルトの bash umask を変更できます。
25.6. ログインシェルのデフォルト umask の変更

/etc/sudoersにおけるumask設定

umask_overrideumaskの設定内容により、動作が異なります。

  • umask_overrideがオフの場合(デフォルト)

    • sudoを実行したユーザのumask設定と、/etc/sudoersにおけるumaskのビット和(union)が適用されます。
    • sudoを実行したユーザのumask設定をそのまま引き継ぎたい場合は、!umaskとするかumask = 0777を指定します。

  • umask_overrideがオンの場合
    sudoを実行したユーザのumask設定を無視して、/etc/sudoersにおけるumaskで上書きします。

/etc/sudoersにおけるumaskのデフォルトは022です。

本記事はumask設定を統一するという趣旨なので、その場合はumask_overrideをオンにします。

internal-sftpにおけるumask

sftpに関し、internal-sftpを使用する場合について触れませんでしたが、/usr/libexec/openssh/sftp-serverと同じオプションが使用できるので、同様に-uを使用できます。

umask設定をテストする際の設定例

本記事のようにumask設定を細かく試す際のやり方として、各設定ファイルのumask設定を無効化(無力化)してから、試したいumask設定のみを変えながらテストするという例を挙げておきます。

この例は、umask設定に限らず、Startup Files(profileやbashrc等)の確認を細かく行いたい場合にも使えます。

以下は、/etc/profileでumask設定を行わないようにする例です。/etc/bashrcの場合も同様です。
umask設定の箇所をコメントアウトし、代わりに何もしないコマンド(:)を置きます。

if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
   #umask 002 ←コメントアウト
   : ←追加
else
   #umask 022 ←コメントアウト
   : ←追加
fi

以下は、/etc/login.defsを使用したumask設定が000になるようにする例です。
他の設定箇所より先に適用される設定なので、テストの際には000にしておくと分かりやすいです。
コメントアウトだけだと、デフォルトの022になってしまいます。

#UMASK          022 ←コメントアウト
UMASK           000 ←追加

以下は、/etc/sudoersでumask設定を行わないようにする例です(説明は前述の通り)。

Defaults umask = 0777

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

suやsudo時のログインシェル、インタラクティブシェル

概要

スクリプトやツールを使用する際、ログインシェルか、インタラクティブシェルかを考慮しないといけないことがあります。
本記事では、susudoを実行した際に起動されるシェルがログインシェルかどうか、インタラクティブシェルかどうかについてまとめます。

本記事の目的

  • susudoを実行した際に起動されるシェルがログインシェルかどうか、インタラクティブシェルかどうかを確認する


目次

基本

前提

対象はbash(GNU Bash)、su、sudoあたりのコマンドです。

記載されている動作確認結果はRHEL8系のものです。別のOSやLinuxディストリビューションについては、コマンド自体の違いは無いか、あっても少ないはずですが、関連するStartup Files(profileやbashrc等)の構成が違うことより結果的に異なる動作になる場合があります。

suやsudo時のログインシェル、インタラクティブシェル

以下のようになります。

コマンド ログインシェル インタラクティブシェル
su
su -
sudo -s
sudo -i
sudo (コマンド)(※1)
sudo su
sudo su -
sudo bash

●:該当

(※1)シェル起動やsu以外のコマンド

上記はサマリです。
詳細については後述します。

詳細

suの各実行方法

  • ユーザを指定しない場合、suはrootとしてコマンドを実行します。

  • 参考:suのman(開発元)
    各OSやディストリビューションに実装されているものと多少違いがあるかもしれませんが、本記事のような基本的なオプションに差異は無いと思います。

su

rootとしてインタラクティブシェルを実行します。

ログインシェルではありません。

su -

オプション無しのsuとの違いは、su -では、ログインシェルとしてシェルを実行します。

suの、--l--loginは全て同じ意味のオプションです。

引数0(argv[0])の先頭に"-"が付与されます。

sudoの各実行方法

  • -uでユーザを指定しない場合、sudoはrootとしてコマンドを実行します。

  • sudoのman(開発元)
    各OSやディストリビューションに実装されているものと多少違いがあるかもしれませんが、本記事のような基本的なオプションに差異は無いと思います。

sudo -s (--shell)

-s(--shell)オプションを使用すると、sudoを実行したユーザの環境変数SHELLが設定されていればその値のシェルを、設定されていなければそのユーザのpasswdエントリにあるシェルをrootとして起動します。

コマンドを指定せずsudo -sだけを実行すると、インタラクティブシェルが起動します。
ログインシェルではありません。

マニュアル(-s, --shell)

sudo -i (--login)

-i(--login)オプションを使用すると、rootとしてログインシェルを起動します。
インタラクティブシェルです。

マニュアル(-i, --login)

sudo (コマンド)

※ここでは、シェル起動以外のコマンド(bashのようなシェルでなく、cpdnfshutdown等)

rootとして、指定したコマンドを実行します。
シェルは起動されません。

sudo su

rootとしてsuを実行します。

rootのパスワードを入力せず、sudoを実行するユーザのパスワードでrootになれます。

sudo su -

rootとしてsu -を実行します。

rootのパスワードを入力せず、sudoを実行するユーザのパスワードでrootになれます。

参考URI

GNU Bash
www.sudo.ws
util-linux(suを含む)

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

ログインシェル、インタラクティブシェルの見分け方(bash)

概要

スクリプトやツールを使用する際、ログインシェルか、インタラクティブシェルかを考慮しないといけないことがあります。
本記事では、現在実行中のシェルがログインシェルかどうか、インタラクティブシェルかどうかを確認する方法についてまとめます。
対象はbash(GNU Bash)です。

本記事の目的

  • 現在実行中のシェルがログインシェルかどうか、インタラクティブシェルかどうかを確認する


目次

基本

ログインシェルかどうかの見分け方

shoptコマンド

shoptコマンドの結果、オプションlogin_shellが"on"の場合、現在実行中のシェルはログインシェルとして起動されています。

(ログインシェルとして起動されている場合)  
$ shopt login_shell
login_shell     on
  • "off"の場合は、非ログインシェルです。
  • shoptをオプション指定せず実行しても確認できますが、他のオプションも一緒に表示されます。

詳細は、4.3.2 The Shopt Builtinに記載があります。

変数$0の確認

$0(Special Parametersの1つ)を確認し、シェル名(bash)の前に-があれば、現在実行中のシェルはログインシェルとして起動されています。

(ログインシェルとして起動されている場合)  
$ echo $0
-bash ←bashの前に"-"あり
  • 注意点として、シェル名(bash)の前に-が無くても、ログインシェルである場合があります。
    例えば、bash --loginbash -lでログインシェルとして起動された場合は、$0のシェル名(bash)の前に-はありません。
  • 対して、前述のshoptの場合は、bash --loginbash -lで起動しても"login_shell on"と表示されます。
    よって、ログインシェルかどうかを判定する際は、$0でなくshoptを使用する方が無難でしょう。
  • 変数$0には、引数無しでbashを起動した場合に引数0(詳細は後述)が格納されます。

詳細は、3.4.2 Special Parametersに記載があります。

インタラクティブシェルかどうかの見分け方

変数$-の確認

$-(Special Parametersの1つ)を確認し、iがあれば、現在実行中のシェルはインタラクティブシェルとして起動されています。

(インタラクティブシェルとして起動されている場合)  
$ echo $-
himBHs ←"i"が含まれている
  • 変数$-にはbashを起動するときに指定されたオプションフラグが格納されます。

詳細は、3.4.2 Special Parametersに記載があります。

変数$PS1の確認

$PS1(shell variablesの1つ)に値が格納されていれば、現在実行中のシェルはインタラクティブシェルとして起動されてい(ると概ね判断でき)ます。

(インタラクティブシェルとして起動されている場合)  
$ echo $PS1
[\u@\h \W]\$ ←プロンプト文字列(primary prompt string)が含まれている
  • $PS1は書き換え可能な変数なので、$PS1に値が格納されていたとしても、インタラクティブシェルであると言い切れるものではありません(ただ上記のようにターミナルでecho $PS1を対話的に実行している時点で、ほぼインタラクティブですが)。
  • インタラクティブシェルかどうかを判定する際は、$PS1でなく通常は書き換えできない$-を使用する方が無難でしょう。

詳細は、3.4.2 Special Parametersに記載があります。

詳細

"ログインシェル"とは

本記事では、bashの起動方法としての"ログインシェル"について記載しています。

/etc/passwdの第7フィールド(shell、ログイン時に起動されるシェルの指定)のことではありません。

ざっくり言うと(厳密ではありません)、ログイン時(login)に起動されるシェルがログインシェルです。

例えば、sshログイン、su -sudo -iによりログインシェルが起動されます。

もう少し詳しく

ログインシェルは、起動時の引数0(argv[0]、argument zero)の最初の文字が-であるシェル、もしくは、--login(-l)オプションを指定して起動されたシェルのことです。

A login shell is one whose first character of argument zero is ‘-’, or one invoked with the --login option.
6.1 Invoking Bash

以下、"引数0"のあたりについて補足します。

実行対象のプログラム自体(ここではbashのこと)と、それを実行するときの呼び出し方(引数0)は、通常同一です(bashを起動するときは"bash"で呼び出す)。
しかし、bash(プログラム)を実行する際、その呼び出し方(引数0)として"bash"でなく"-bash"を指定する場合があります。
bashは、この引数0の先頭に-があると、ログインシェルとして起動します。

具体的には、bashに含まれるビルトインコマンドの1つであるexecコマンドは、-lオプションにより引数0の先頭に-を追加してコマンドを実行することができます。つまり、exec -l bashにより、bash実行時の引数0として"-bash"を指定することになります。

システムへのログイン時に実行されるloginは、この処理を行うことでログインシェルとして起動しているようです。

If the -l option is supplied, the shell places a dash at the beginning of the zeroth argument passed to command. This is what the login program does.
builtinのexecコマンド

他に、exec -a -bash bashも同様の意味です。

execコマンド自体についてのより詳細な内容は見当たりませんが、exec系の関数が参考になると思います。

なお、bash --login(-l)は、インタラクティブシェルの場合exec -l bashと同等の意味です。

"インタラクティブシェル"とは

本記事では、bashの起動方法としての"インタラクティブシェル"について記載しています。

ざっくり言うと(厳密ではありません)、ターミナル経由で対話的に入力、出力するシェルがインタラクティブシェルです。

ターミナルに[user@host /dir]$のようなプロンプトが表示されたシェル環境があればインタラクティブシェルです。

もう少し詳しく

インタラクティブシェルは、以下のいずれかに該当するシェルです。

  • オプションでない引数(スクリプトファイル等)が指定されていない、かつ-cオプションが指定されていない、かつ入力と出力が端末に接続されている(isatty関数で判断)
  • -iオプションが指定されている

インタラクティブシェルの起動時に-sオプションを指定すると、positional parameters($0~$9)を設定できます。

参考URI

GNU Bash

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