[ruby-dev:39606] [Feature:trunk] Dir instance methods for relative path

[Nobuyoshi Nakada-2]

なかだです。

http://www.ipa.go.jp/security/fy20/reports/tech1-tg/2_05.html を
みて思い出したんですが、相対パスを使うDirのインスタンスメソッド
はどうでしょうか。実装はmvmブランチにあります。

$ ./ruby -v -e 'p Dir.open("ext"){|d|d.open("extmk.rb"){|f|f.gets}}'
ruby 1.9.1 (2008-12-25 mvm 20976) [i686-linux]
"#! /usr/local/bin/ruby\n"

$ mkdir tmp
$ touch tmp/x tmp/y
$ ./ruby -e 'p Dir.open("tmp"){|d|d.unlink("x")}'
0
$ ls tmp/
y

--
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

[Yukihiro Matsumoto]

まつもと ゆきひろです

In message "Re: [ruby-dev:39606] [Feature:trunk] Dir instance methods for relative path"
    on Mon, 2 Nov 2009 17:48:13 +0900, Nobuyoshi Nakada <nobu@...> writes:

|http://www.ipa.go.jp/security/fy20/reports/tech1-tg/2_05.html を
|みて思い出したんですが、相対パスを使うDirのインスタンスメソッド
|はどうでしょうか。実装はmvmブランチにあります。

openがあり、unlinkがあり、その他ディレクトリ以下のファイルを
操作するさまざまなメソッドがあるとなると(いくつ定義しました
か？)、なんかDirの役割がぼやけて来ませんかねえ。

反対というほどではないのですが。

[KOSAKI Motohiro]

kosakiです

よくわかってないのですが。

> まつもと ゆきひろです
>
> In message "Re: [ruby-dev:39606] [Feature:trunk] Dir instance methods for relative path"
>     on Mon, 2 Nov 2009 17:48:13 +0900, Nobuyoshi Nakada <nobu@...> writes:
>
> |http://www.ipa.go.jp/security/fy20/reports/tech1-tg/2_05.html を
> |みて思い出したんですが、相対パスを使うDirのインスタンスメソッド
> |はどうでしょうか。実装はmvmブランチにあります。
>
> openがあり、unlinkがあり、その他ディレクトリ以下のファイルを
> 操作するさまざまなメソッドがあるとなると(いくつ定義しました
> か？)、なんかDirの役割がぼやけて来ませんかねえ。
>
> 反対というほどではないのですが。

openat()はセキュリティ的な観点から、推奨していくべきなので、
簡単に使えるようになるのは賛成です。

でも、上記メールから

open(dir, relative-path)

というメソッドでダメな理由がよく分かりませんでした。解説お願いしても
よいでしょうか？

[Nobuyoshi Nakada-2]

なかだです。

At Tue, 3 Nov 2009 00:51:18 +0900,
KOSAKI Motohiro wrote in [ruby-dev:39611]:
> でも、上記メールから
>
> open(dir, relative-path)
>
> というメソッドでダメな理由がよく分かりませんでした。解説お願いしても
> よいでしょうか？

dirは、Dirかディレクトリに対応するFileのインスタンスということで
すか? それも可能だとは思いますが、Dir#to_pathも定義されるように
なったので区別が難しくなったんじゃないでしょうか。

--
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

[Tanaka Akira-3]

In article <4aee9ccb.0706c00a.3bfe.ffffc422@...>,
  Nobuyoshi Nakada <nobu@...> writes:

> http://www.ipa.go.jp/security/fy20/reports/tech1-tg/2_05.html を
> みて思い出したんですが、相対パスを使うDirのインスタンスメソッド
> はどうでしょうか。実装はmvmブランチにあります。

openat については Dir のインスタンスメソッドも悪くないと思う
のですが、renameat, linkat は Dir がふたつ必要でそうはできな
いので、ちょっと一貫性がなぁ。
--
[田中 哲][たなか あきら][Tanaka Akira]

[KOSAKI Motohiro]

> なかだです。
>
> At Tue, 3 Nov 2009 00:51:18 +0900,
> KOSAKI Motohiro wrote in [ruby-dev:39611]:
> > でも、上記メールから
> >
> > open(dir, relative-path)
> >
> > というメソッドでダメな理由がよく分かりませんでした。解説お願いしても
> > よいでしょうか？
>
> dirは、Dirかディレクトリに対応するFileのインスタンスということで
> すか? それも可能だとは思いますが、Dir#to_pathも定義されるように
> なったので区別が難しくなったんじゃないでしょうか。

うむむ。なるほど。

単純な疑問として、最初に思ったのは自分が相対パスでファイルを
開きたい状況になったときに、「まっさきに調べるのがDirクラスのAPIリファレンスか？」
というとNOだと思ったからです。

自分なら、「ファイルオープン」ってどうやるんだっけ？と、思考が働くので

open(dir, relative-path) or
openat(dir, relative-path)

のほうが、APIに一発ヒットできてナイスかなと。まあ直感なんですが。


# ところで、みなさんがopenatが嫌なのは名前がダサイからでしょうか？

[Yukihiro Matsumoto]

まつもと ゆきひろです

In message "Re: [ruby-dev:39620] Re: [Feature:trunk] Dir instance methods for relative path"
    on Tue, 3 Nov 2009 12:57:58 +0900, KOSAKI Motohiro <kosaki.motohiro@...> writes:

|単純な疑問として、最初に思ったのは自分が相対パスでファイルを
|開きたい状況になったときに、「まっさきに調べるのがDirクラスのAPIリファレンスか？」
|というとNOだと思ったからです。

そうですよねえ。

|自分なら、「ファイルオープン」ってどうやるんだっけ？と、思考が働くので
|
|open(dir, relative-path) or
|openat(dir, relative-path)
|
|のほうが、APIに一発ヒットできてナイスかなと。まあ直感なんですが。

中田さんがすでに指摘したような理由でopen(dir, relative-path)
は難しそうです。open(relative-path, "rw", base: dir) とかな
ら可能かもしれませんが、ちょっと冗長な気もします。

|# ところで、みなさんがopenatが嫌なのは名前がダサイからでしょうか？

ダサいというか、openateという単語の省略形かと思って辞書引きま
した、最初。そんな単語ないんですけど。create → creat みたい
なものかと思って。

[NARUSE, Yui-2]

成瀬です。

Yukihiro Matsumoto wrote:

> まつもと ゆきひろです
>
> In message "Re: [ruby-dev:39620] Re: [Feature:trunk] Dir instance methods for relative path"
>     on Tue, 3 Nov 2009 12:57:58 +0900, KOSAKI Motohiro <kosaki.motohiro@...> writes:
>
> |単純な疑問として、最初に思ったのは自分が相対パスでファイルを
> |開きたい状況になったときに、「まっさきに調べるのがDirクラスのAPIリファレンスか？」
> |というとNOだと思ったからです。
>
> そうですよねえ。

そもそも、根本的に openat の API って実装の都合が出過ぎていませんかね。
C 言語の関数ならばともかく、Ruby の API としては、
もうちょっとユースケースベースの API にしないと使われない気がします。
(使うべき人が使う API でいいやと割り切るという考えもあるでしょうが)

例に出されているテンポラリディレクトリの削除については、
とりあえずどっかしらに用意して、それを fileutils で使えばいいのでしょうが、

> ./ruby -v -e 'p Dir.open("ext"){|d|d.open("extmk.rb"){|f|f.gets}}'
の場合だと、人工的な例を言うのを差し引いても、
一般の人が使ってくれるとははなかなか考えづらいように感じます。
あとは、そのディレクトリの下の
d.open("some_directory"){|dd| ...}もあるなぁとか。

っと思ったけど、
> ./ruby -v -e 'p open(["ext", "extmk.rb"]){|f|f.gets}}'
> ./ruby -v -e 'p open([dir, "extmk.rb"]){|f|f.gets}}'
を許すなら join の手間が省けるので使ってくれるかなぁ。

これ以外だと、__DIR__ と絡めるとかですかねぇ。

--
NARUSE, Yui  <naruse@...>

[Nobuyoshi Nakada-3]

チケット #2325 が更新されました。 (by Yui NARUSE)

ステータス OpenからClosedに変更

重複なので閉じます
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2325

----------------------------------------
http://redmine.ruby-lang.org

[Nobuyoshi Nakada-3]

チケット #2324 が更新されました。 (by Yui NARUSE)

ステータス ClosedからOpenに変更

おおう、先にduplicatedをつけてしまった
----------------------------------------
http://redmine.ruby-lang.org/issues/show/2324

----------------------------------------
http://redmine.ruby-lang.org

[Nobuyoshi Nakada-2]

なかだです。

At Tue, 3 Nov 2009 23:18:49 +0900,
NARUSE, Yui wrote in [ruby-dev:39625]:
> そもそも、根本的に openat の API って実装の都合が出過ぎていませんかね。
> C 言語の関数ならばともかく、Ruby の API としては、
> もうちょっとユースケースベースの API にしないと使われない気がします。
> (使うべき人が使う API でいいやと割り切るという考えもあるでしょうが)

何か別のクラスを新設したほうがいい、ということでしょうか。

> > ./ruby -v -e 'p open(["ext", "extmk.rb"]){|f|f.gets}}'
> > ./ruby -v -e 'p open([dir, "extmk.rb"]){|f|f.gets}}'
> を許すなら join の手間が省けるので使ってくれるかなぁ。

手間は省けますが、symlink attackには無意味です。

--
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

[NARUSE, Yui-2]

成瀬です。

Nobuyoshi Nakada wrote:
> At Tue, 3 Nov 2009 23:18:49 +0900,
> NARUSE, Yui wrote in [ruby-dev:39625]:
>> そもそも、根本的に openat の API って実装の都合が出過ぎていませんかね。
>> C 言語の関数ならばともかく、Ruby の API としては、
>> もうちょっとユースケースベースの API にしないと使われない気がします。
>> (使うべき人が使う API でいいやと割り切るという考えもあるでしょうが)
>
> 何か別のクラスを新設したほうがいい、ということでしょうか。

えぇ、例えば、Fileinfo クラスを作り、親ディレクトリのファイルハンドルと
そのディレクトリからの相対パスを持つ。

で、例えば Dir.foreach なら以下のように使う、と。
Dir.foreach("/tmp") do |fileinfo|
  fileinfo.open{|f| f.read} if fileinfo.file?
end

>>> ./ruby -v -e 'p open(["ext", "extmk.rb"]){|f|f.gets}}'
>>> ./ruby -v -e 'p open([dir, "extmk.rb"]){|f|f.gets}}'
>> を許すなら join の手間が省けるので使ってくれるかなぁ。
>
> 手間は省けますが、symlink attackには無意味です。

いや、open 内で join するのではなくて、
open の中で ext を開いてから openat で extmk.rb を開いたり、
dir から openat で extmk.rb を開くという話です。

現在 open(File.join(dir, "extmk.rb")){|f|f.gets}} などと書いているところを、
open([dir, "extmk.rb"]) と書くようにさせる、だと受け入れやすいかなと。

--
NARUSE, Yui  <naruse@...>

[Tanaka Akira-3]

In article <4AF03BC0.6090104@...>,
  "NARUSE, Yui" <naruse@...> writes:

> そもそも、根本的に openat の API って実装の都合が出過ぎていませんかね。
> C 言語の関数ならばともかく、Ruby の API としては、
> もうちょっとユースケースベースの API にしないと使われない気がします。
> (使うべき人が使う API でいいやと割り切るという考えもあるでしょうが)

良く使うものに最適化した API はもちろん重要ですが、できるこ
とをなんでもできる API もまた重要です。

なんでもできるのに良く使うものに最適化してある、というのがい
ちばんですが。

In article <4AF305C2.8080007@...>,
  "NARUSE, Yui" <naruse@...> writes:

>>>> ./ruby -v -e 'p open(["ext", "extmk.rb"]){|f|f.gets}}'
>>>> ./ruby -v -e 'p open([dir, "extmk.rb"]){|f|f.gets}}'
>>> を許すなら join の手間が省けるので使ってくれるかなぁ。
>>
>> 手間は省けますが、symlink attackには無意味です。
>
> いや、open 内で join するのではなくて、
> open の中で ext を開いてから openat で extmk.rb を開いたり、
> dir から openat で extmk.rb を開くという話です。

symlink attack を防ぐためには ext を開いた結果が意図したもの
であることを確認しないといけないので、そういう話ならセキュリ
ティ的な効果はありませんね。

配列の第一要素が Dir (や IO) のときに、その fd を openat の
dirfd に渡すという話ならセキュリティ的な意味はあると思います。

まぁ、その配列の形式は pathname に素直に入れられないという問
題があるんですが、それを除けば悪くはないと思います。
--
[田中 哲][たなか あきら][Tanaka Akira]

[Tanaka Akira-3]

In article <87639nskdz.fsf@...>,
  Tanaka Akira <akr@...> writes:

> 配列の第一要素が Dir (や IO) のときに、その fd を openat の
> dirfd に渡すという話ならセキュリティ的な意味はあると思います。

いろいろ考えると、この、いままでパス名を受け付けていたところに
[dir, str] という 2要素の配列を受け付けるというのがいいんじゃ
ないですかね。

* メソッドを増やさないので覚えることが少ない

* File.rename と File.link も同じ方針で扱えるので覚えること
  が少ない
  (renameat と linkat はディレクトリをふたつ指定できるので
  Dir のインスタンスメソッドという形では扱えない)

* to_path の返り値も [dir, str] を受け付けるようにすれば
  Pathname も扱える
  (Pathname は dir も記録できるように拡張し、
  Pathname#to_path が [dir, str] を返す)

概念的なことをいうと、パス名というのがファイルシステム内でファ
イルを同定するものとすると、相対パスはむしろそれ単独では不完
全なものです。その場合、起点となる Dir と対にしたほうが意図
を確実に表現できるので、その対をひとまとまりとして扱ったほう
が意図せざることが起きにくい、安定したプログラムを書きやすく
なるでしょう。

欠点は、機能の有無を respond_to? では判定できないところです
かね。メソッドが増えないので。

あとは dir が close されるとその dir を含む Pathname が使え
なくなることかな。それはまぁそういうものだということで。

なお、openat 等がない環境については、renameat と linkat を除
けば、fchdir と GVL があればそれなりにどうにかなるのではない
かと思います。(fchdir で一時的にカレントディレクトリを変えて
してシステムコールを発行する。GVL により他のスレッドが chdir
する可能性がなければ、これは安全なはずです)
--
[田中 哲][たなか あきら][Tanaka Akira]

[Tanaka Akira-3]

In article <87bpj5som4.fsf@...>,
  Tanaka Akira <akr@...> writes:

> いろいろ考えると、この、いままでパス名を受け付けていたところに
> [dir, str] という 2要素の配列を受け付けるというのがいいんじゃ
> ないですかね。

これはこれでなんでもできる API として良いのですが、ひとつ考
えられる異なる形の API としては、ワーキングディレクトリをス
レッド毎にしてしまう、というものがあるかもしれません。

ただ、メソッドとかの形式をぜんぜん変えないでそうしてしまうと、
それを実現できない環境でどうしたらいいのか謎ではあります。
--
[田中 哲][たなか あきら][Tanaka Akira]