アカウント名:
パスワード:
パーミッションで実行権限を付与しても ACL で実行権限が落とされていると、普段のクセで ls -l して確認後に ./foo.sh とかやっても実行できなくて悩むとか、そういうオチでしょうか。
管理の都合上 default deny に倒した後で、LDAP の登録情報に従ってグループで ACL を利用して読み込み権限を付与するようなやり方を行うと -r に失敗してくれたりするのですよね。当然話を -x にしても同じです。
DAC (パーミッション)、MAC (SELinux)、ACL と既存機能の間で全く整合性が取れていないのです。こういう点は非合理的じゃないですか?
なお、Windows で NTFS であれば、ダウンロード先フォルダやマイドキュメントなどから読み取りと実行の権限を外したり、実行の拒否を設定して子孫継承させておくだけで、結構簡単に安全にできるように思います。.exe は実行されないけれど、.doc ダブルクリックなどは通用しますので。
単純に読み取りと実行を拒否にしようとすると読み取りまで拒否されるので、詳細設定の方から実行権限だけ拒否ですね。
失礼。確かにフォルダだと実行だけではなく閲覧まで禁止されますね。まさにディレクトリの実行ビットを落とした扱いで……。 orz
フォルダではなくファイルで確認していました。ファイルだと実行権限のみ落とせるのですが。
で、別のやり方としては、ローカルセキュリティポリシーのソフトウェアの制限ポリシーに以下のような設定を入れるといけます。基本はデフォルトの規則のまま、通常通りアプリケーションが実行できる状態にしておきます。その上で、追加の規則で以下のような設定を入れます。
これらに加えてデスクトップやダウンロードファイルの保存先などに制限しないポリシーを必要に応じて追加する形でしょうか。
My Documents 単位で止めずにユーザプロファイルフォルダ単位で止めることで、「とりあえず実行してみる」パターンを抑えつつ、デスクトップ等を許容することで必要に応じて実行できるようにできます。
家庭向け製品だと適用できませんが、ビジネス向けなら有効な手段だと思います。ビジネス向けの場合はグループポリシーの同じ項目から、でしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
ファイル名の表示なんて見ない (スコア:2, 興味深い)
ファイル名表記で確認するなんて、「○○.txt .exe」で懲りてないのか、なんて思ったり。
Re:ファイル名の表示なんて見ない (スコア:2, すばらしい洞察)
何10年経っても変わらないんだうけど。
Re:ファイル名の表示なんて見ない (スコア:3, 参考になる)
Win2k以降のWinNT系列OSは、環境変数PATHEXTに拡張子が列挙されていて、ファイルシステムで
実行可能ビットが立っているものが実行可能なファイルです。
.EXEは特別扱いの拡張子ではなく、デフォルトでその条件を満たしているだけに過ぎません。
CreateProcess()では元々どんなファイル名のファイルでも実行可能です。
PATHEXTさえ適切に設定すれば、どんな拡張子のファイルでも、拡張子なしのファイルでもエクスプローラやcmd.exeから実行可能です。
Re:ファイル名の表示なんて見ない (スコア:1)
>PATHEXTさえ適切に設定すれば、どんな拡張子のファイルでも、拡張子なしのファイルでもエクスプローラやcmd.exeから実行可能です。
参考までに拡張子なしのファイルのPATHEXT(と実行可能ビット)の設定方法を教えてください
これができればshellbang#!の特殊処理がエレガントになると思うんですが(cygwinとか、activeperlみたいにスクリプトをbatに変換しなくてすむ)
Re:ファイル名の表示なんて見ない (スコア:1, 参考になる)
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Unknown\shell]
@="exec"
[HKEY_CLASSES_ROOT\Unknown\shell\exec]
@="\"c:\\unix like tools\\#!.exe\" \"%1\""
こんなんでどう?
先頭行に#!自身の呼び出し記述がなければ、HKEY_CLASSES_ROOT\Unknown\runasやopendlgを#1.exeが代わりに実行してやればエレガントになるよ。
実行可能ビットはフォルダの中が覗ける場合には通常付いている。
Re:ファイル名の表示なんて見ない (スコア:0)
Re:ファイル名の表示なんて見ない (スコア:1, すばらしい洞察)
MacOSですら、Xになって、.appと名前が違うだけで“同レベルに堕ちた”し。
Re:ファイル名の表示なんて見ない (スコア:2, 参考になる)
実態はフォルダ構造であり、その内部にデータやら実行バイナリやらのファイルが
含まれています。
そんでバイナリが実行可能かどうかは通常のUNIXと同じくumaskによるものです。
これには拡張子は影響しません。
また.appフォルダ全体にも同様のumaskが設定されておりますので
単に「拡張子がなんであるか」で実行されるかどうかが決まっているわけではありません。
Re:ファイル名の表示なんて見ない (スコア:0)
付けて拡張子を非表示にした状態のアプリケーションを
一部のアプリケーション(Final Cut Proとか)のドキュメント
配布形態として用いていたりします。
どうも,複数の言語のドキュメントのなかから
環境にあったものを表示させるのにこういう形態を
取っているようですが…
Re:ファイル名の表示なんて見ない (スコア:0, 余計なもの)
ここ以降 [srad.jp]にあるUNIX系のは非合理的の極みだし、旧Macのファイルタイプ&クリエイター方式は分かりやすいけど運用がめんどくさい。
実際にはそれほどの手間じゃないけどクリエイターを一元管理するためにAppleに登録する必要があったしね。
分かりやすさと合理性と運用面の落としどころで、今以上の構想があるなら特許でも取れば?
Re:ファイル名の表示なんて見ない (スコア:1)
どこがどう非合理的なんだか。
拡張子みてどうこうするより、はるかに合理的
Re:ファイル名の表示なんて見ない (スコア:1)
パーミッションで実行権限を付与しても ACL で実行権限が落とされていると、普段のクセで ls -l して確認後に ./foo.sh とかやっても実行できなくて悩むとか、そういうオチでしょうか。
管理の都合上 default deny に倒した後で、LDAP の登録情報に従ってグループで ACL を利用して読み込み権限を付与するようなやり方を行うと -r に失敗してくれたりするのですよね。当然話を -x にしても同じです。
DAC (パーミッション)、MAC (SELinux)、ACL と既存機能の間で全く整合性が取れていないのです。こういう点は非合理的じゃないですか?
なお、Windows で NTFS であれば、ダウンロード先フォルダやマイドキュメントなどから読み取りと実行の権限を外したり、実行の拒否を設定して子孫継承させておくだけで、結構簡単に安全にできるように思います。.exe は実行されないけれど、.doc ダブルクリックなどは通用しますので。
Re:ファイル名の表示なんて見ない (スコア:1)
単純に読み取りと実行を拒否にしようとすると読み取りまで拒否されるので、詳細設定の方から実行権限だけ拒否ですね。
Re:ファイル名の表示なんて見ない (スコア:0)
Re:ファイル名の表示なんて見ない (スコア:1)
失礼。確かにフォルダだと実行だけではなく閲覧まで禁止されますね。まさにディレクトリの実行ビットを落とした扱いで……。 orz
フォルダではなくファイルで確認していました。ファイルだと実行権限のみ落とせるのですが。
で、別のやり方としては、ローカルセキュリティポリシーのソフトウェアの制限ポリシーに以下のような設定を入れるといけます。基本はデフォルトの規則のまま、通常通りアプリケーションが実行できる状態にしておきます。その上で、追加の規則で以下のような設定を入れます。
これらに加えてデスクトップやダウンロードファイルの保存先などに制限しないポリシーを必要に応じて追加する形でしょうか。
My Documents 単位で止めずにユーザプロファイルフォルダ単位で止めることで、「とりあえず実行してみる」パターンを抑えつつ、デスクトップ等を許容することで必要に応じて実行できるようにできます。
家庭向け製品だと適用できませんが、ビジネス向けなら有効な手段だと思います。ビジネス向けの場合はグループポリシーの同じ項目から、でしょうか。
Re:ファイル名の表示なんて見ない (スコア:0)
AthlonPCを買ったんで、DEPを有効にしたら動かないアプリの多いこと多いこと。
デフォルトを前提に組まれちゃうと安全な設定で動かなくなるものが多すぎる。
それにしてもWindowsのパーミッションの設定の分かり辛さは異常。メールフォルダとか
Winnyのダウンロードフォルダとか危険な場所の実行を禁じるだけでもほとんどの危険は
回避できるというのに。
Re:ファイル名の表示なんて見ない (スコア:0)
# できないだろうなぁ