「デュアルブート」の版間の差分
Notion-MW |
Notion-MW |
||
| 40行目: | 40行目: | ||
<syntaxhighlight lang="javascript">/dev/sda2 /media/ddrive ntfs-3g noauto,rw,nofail 0 0</syntaxhighlight></li></ul> | <syntaxhighlight lang="javascript">/dev/sda2 /media/ddrive ntfs-3g noauto,rw,nofail 0 0</syntaxhighlight></li></ul> | ||
<span id=" | <span id="bitlocker有り"></span> | ||
=== | === Bitlocker有り === | ||
ntfs-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2] | ntfs-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2] | ||
| 63行目: | 63行目: | ||
recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。 | recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。 | ||
=== | <span id="permissions-inheritについて"></span> | ||
=== permissions, inheritについて === | |||
[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] | [https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] 詳しくはこちらも参照。 | ||
まず、マウントオプションとして<strong>permissions</strong>を指定しない限り、ntfs-3gでマウントしたファイルは全てパーミッション・所有者が固定（uid, gid, umaskなどで指定）となり、個別のファイルについて変更することはできない。 | |||
そして、この場合、ntfs-3g経由で作成したファイルはWindows側で見るとすべてAdministratorの所有となり、さらにEveryoneにフルコントロール権限が付与される（この動作を変更するのは筆者の知る限り不可能）。 | |||
Linuxではフォルダの実行権限（x）が無ければその中に含まれたファイルにはアクセスが通らず、パスを推測することも不可能だが、Windowsではたとえ一切権限のないフォルダであっても中にあるファイル・フォルダのパスがわかれば直接パスを打つことでアクセスが通ってしまうようである（試した限り）。そのため、permissions無しでntfs-3gで作成したファイルはパスさえわかればWindows上の全ユーザーが閲覧・編集・削除できる状態ということになる。 | |||
従って、Gitを使用する場合や複数ユーザーで使用したい場合などパーミッション管理が必要なデータを扱う場合はもちろん、単に中にあるデータを保護したいという場合でもpermissionsオプションを指定することが必須になる。 | |||
次に、permissionsを指定して、かつUserMappingを指定しない場合、Linux上でrootが所有するファイルをWindows側で見ると、全てAdministratorsの所有物になり（ここはpermissionsがない場合と同じ）、そのアクセス権はLinux上での見え方と概ね一致するように設定されるようである。他のユーザーが所有するファイルにはS-1-5-21-3141592653-589793238-462643383-10000というような上位桁が円周率に由来する（この部分はハードコードされている）SIDが割り当てられ、こちらもアクセス権が適切に設定される。UserMappingを指定することで、このSIDの部分の割り当てを変更することができる。 | |||
Windowsに挙動を近づけるための他のオプションとしては<strong>inherit</strong>というのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは<u>所有者を継承するオプションではない</u>（そして、所有者が違えばまともに継承もされない）。 | |||
以上のことから、Windowsの一般ユーザーフォルダの内容などをLinuxから良い感じに（Windows側の権限設定を汚染せずに）使えるようにするには、明示的なUserMappingが事実上必須であることがわかる。 | |||
一方で、Administrator所有・全ユーザー閲覧可能（あるいは不可能）、といった、Windows側の全ての一般ユーザーに対して共通のアクセス権を適用する設定であれば、UserMappingを使用しなくても簡単に設定が可能である。個人用PCかつ、画像・動画などのメディアファイルやLinuxでしか使用しない大きめのソフトウェアを入れておく用途であれば、こちらで問題ないだろう。 | |||
Linux側で別ユーザーの所有に見せたい場合は、上記のS-1-5-21-3141592653-589793238-462643383-10000のようなSIDが見えてしまう状態でもよければ（かつ、権限設定にも問題がなければ）それでもいいし、下記のbindfsと併用する方法もある。いずれにしても、Linux側で全員が読み取り・書き込み・実行が可能なファイルは、Linux側での親フォルダの権限によらず、Windows側では（パスさえわかれば）対応する権限でアクセスができてしまうということに注意が必要である。 | |||
また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる（実行権限を外すと.exeなどが実行できなくなる）。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで（これがデフォルトであるため）コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。 | |||
==== bindfs ==== | ==== bindfs ==== | ||
既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。 | |||
<syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight> | <syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight> | ||