これは便利なのだが、ただ困ったことに 32111/tcp が閉じられているなど諸々の理由でUSBリダイレクションがうまくいかない場合、下記のエラーメッセージが頻発して操作性が悪くなる。
 |
| USBリダイレクトに失敗するとこのメッセージが何度も何度も出る |
Windows 版と異なり、Mac 版の USBリダイレクションはそのままでは有効にならず、一度メニューからサービスを開始させる必要がある。
 |
| USBリダイレクトを使うには、まず「リモートデスクトップUSBサービス」を開始させる必要がある これはデフォルトでは有効になって板に |
 |
| 開始させようとすると上記警告と、管理権限のパスワード入力が求められる 必要なのは最初の一度だけで、有効にしたら最後 次回以降の起動では必ず有効になる |
ところが、標準メニューではこれを有効にすることはできても向こうに戻すことができない。これは不便だ。
なので、調べてみた。
この「リモートデスクトップUSBサービス」だが、二つの要素でできている。
まずはユーザランド側で、「vmware-usbarbitrator」と「vmware-view-usbd」という二つのプロセスが起動する。vmware-usbarbitrator は VMware Fusion にも搭載されているUSBの調停プロセスで、おそらく OS X からUSBデバイスを引き取るのに使われているのであろう。
もう一つはカーネル側で、「vmioplug.kext」という KEXT (カーネル拡張) 。これが USBの通信を引っ張り出して、usbarbitrator などに渡しているものと思われる。
そして、インストール(dmg からコピー)直後の ViewClient ではこの vmioplug.kext がコピーしたユーザの権限になっている。対して「リモートデスクトップUSBサービスを開始」を実行した後はこれが root:wheel に権限が書き換えられている。
セキュリティのため、OS X では root:wheel 、権限が 755 な kext 以外をカーネルにロードできないようになっている。カーネルは最高特権で動作するので、ここに一般ユーザで書けてしまうファイルを書き込むのは極めて危険であり、同等権限を要求することで安全性を揚げているのだ。( root:wheel のファイルを用意できる時点でそのシステムは落とされているから、それ以上厳しくしても意味がない )
なのでこの vmioplug.kext の権限を root:wheel でなくしてしまう、ロードできないようにすることで元に戻す、「リモートデスクトップUSBサービスを開始」を選択する前の状態に戻すことができる。
とりあえずはこれでしのげた。
