DenoでUnixコマンドを実装して将来性を確信した

--- type: slide slideOptions: controls: false slideNumber: false progress: true --- # DenoでUnixコマンドを実装して将来性を確信した  --- ## 皆さんこんにちは！ :wave: ---  My Profile Otogawa Katsutoshi freelance backend enginner interesting deno, golang, python, and more... [twitter account](https://twitter.com/k_otogawa)  ---  ## 突然ですがみなさん！jsは好きですか？ :sunglasses: --- ## 私は大好きです！ ---  ## 今回何しに来たか?というと個人開発でdenoを使っていて、これまでに他の言語、ランタイムに無い可能性、将来性を見出したのでその紹介に来ました。 ## 要するに --- ## denoの布教に来ました ![布教](https://i.imgur.com/FqNC6gr.png =x500) 入信したら幸せになれます! --- ## 前提条件話す人のDenoの知識 1. 業務で使ったことは無い 2. 触り初めて1ヶ月経つかどうか ![ご了承下さい](https://i.imgur.com/GQNd5XU.png =x500)  --- ## そもそもなんでDenoを触ったきっかけは ![問題提起](https://i.imgur.com/N4Umxfe.png =x500) --- ## それなりに経験あるし、名刺代わりになるようなアプリケーションが欲しい!と思ったコンテナ管理用のレポジトリを作成、管理するアプリケーションを作ることに。できたらOSSとして公開しようかなと。  --- ## ある程度nodejsで書き進めていた！しかし...書き続けていて今後の懸念点が見つかる。  --- ## nodejs採用の懸念点 nodejsだと 1. コマンドを実行するのが難しい。 2. 第三者から見た安全性を担保するのが難しい。 --- ## 1. コマンドを実行するのが難しい。標準で備わっているコマンド実行するための関数が難解かつ見辛い。 --- ## nodejsでもzxだと頑張れるが googleのzxを採用したら楽に。  しかし、zxはエラーコードが0以外は全て例外と見なすため... --- ## zxだとtry catch地獄! シェルの世界では別に異常でなくても0以外のエラーコードは頻繁に使う。  通常のシェルスクリプトやコマンド実行するためのframeworkとしては癖がある。一応、0以外でも例外を投げないようにもできるが...  --- ## 2. 第三者から見た安全性を担保するのが難しい作りたいものがコンテナとそのレポジトリ周りのアプリケーション  1. 作りとして結構ファイルの読み書きを行う 2. 結構通信を送る作りになる 3. 結構管理者権限も必要(これはコンテナ扱うのでどうしても必要)  --- ## どこの馬の骨が作ったものかわからんやつが作ったものとしてとても使いたく無い!  --- ## 有名なエンジニア、会社が作っているから安全これはこれで、全然ロジカルじゃ無い  --- ## エンジニアも会社も常に闇落ちする可能性がある ![闇落ち](https://hackmd.io/_uploads/BJ48hh4J6.png =x400)  --- ## 安全性を担保するなら使いたい人が 1. ソースコードを読む必要がある。 2. 権限の汚染の対策。  --- ## 1. 疑うならソースコードを読む必要がある読むとしてもすべてソースコードとして提供されているわけではない。謎のバイナリが合って、そこからスクリプトとしてマッピングして呼び出しているなら.. みなさん!どうしますか？ --- ## そうだね！逆コンパイルだね！:angel: ![そうだねプロテイン](https://hackmd.io/_uploads/H1vVhJzxp.png =x400)  --- ## 逆コンパイルまでやるならソースコード読むの辛すぎ... 1. コメントは無い。 2. どこがnullなのかわからん。  --- ## 読んでいて適当なところで妥協しがち ![匙を投げる](https://hackmd.io/_uploads/ByNQp1zep.png =x400) --- ## ソースコードを疑うなら、ハイスキルなエンジニアでも時間がかかるこういうのやっていられないから仮装環境とかでサンドボックス環境を用意するけど、仮装環境ゆえの縛りがあったりするから、すべてこれで解決はできない。 --- ## 2.権限の汚染の対策どういうことかというと、 --- ## sudoにせよ、管理者権限にせよ下記を実行するということは、helloに含まれている処理全てを管理者権限で実行するということ。 ```bash= # example sudo hello ``` --- ## そもそも管理者権限必要無い処理も含まれる ```bash= # 必要無い処理 cat /etc/hosts systemctl start httpd #　やばい処理 rm -rf /* ``` --- ## そんなの関係ねぇ！ 1. 必要無い処理 2. 必要な処理 3. ヤバい処理そんなの関係ねぇとすべて管理者権限で実行する。  --- ## 本来やりたかったことは特定のコマンド、処理のみ管理者権限を与えたかった。 ---  ## 改めて懸念点(改めて) 1. コマンドを実行するのが難しい。 2. 第三者から見た安全性を担保するのが難しい。  --- ## ここでたまたまDenoというjsの言語ランタイムをちょっと前に聞いたことを思い出す。  --- ## twitterで炎上したじゃ無いですか？あの時、「typescriptがレガシーなんて新しいDenoでもデフォルトで採用されているのにあり得ない！」とかいうエンジニアが何人かいたなぁ.. --- ## Deno?!なんやそれ？ --- ## 期待せずに調べてみるキラキラ言語で、自分には合わんかも... --- ## 想像以上に自分に作りたいものにマッチしていた! ![驚く](https://hackmd.io/_uploads/H1VlONaxp.png =x400) --- ## 先ほどの懸念点全部をこれ採用で解決できる! --- ## 1. コマンドを実行するのが難しい。 DenoはデフォルトでDeno.Commandという結構簡単に外部コマンドを実行するための関数があるのでこれで解決できる。シンプルだが、本体にあるならそれに越した事はない。 --- ## 2. 第三者から見た安全性を担保するのが難しい Denoならパーミッションで担保できそう。  --- ## Denoのパーミッションどこのファイル読み込むか？やどこに通信投げるかで、いちいち処理が止まる仕組み。実行しているユーザーがやばい処理に気づきやすい。  --- ## 実際やってみましょう今回denoでwhichコマンドを実装したので使ってみましょう!  ---- ## こいつめっちゃ聞いてくるやんwww! ![大笑い](https://hackmd.io/_uploads/Byuof9uka.png =x400) --- ## あらかじめ許可を与えることができる! 普段使い辛そう！とか思う人はdeno run時やコンパイル後のバイナリに対して、 -Aを引数として与えると、すべて飛ばせる。 ```bash= # ,区切りで特定の値だけ許可 deno run --allow-read=/usr/local/bin,/usr/local/sbin which.ts # 読み込みはすべて許可 deno run --allo-read which.ts # 外部コマンドは全て許可 deno run --allow-run which.ts # 全てのパーミッションの許可を与える。 deno run -A which.ts ``` --- ## 全ての許可を与えると言うことはセキュリティ的なリスクをユーザーが負うということ。リスクを負うといっても、これで初めて、普通のプログラミング言語と同じぐらいのセキュリティ基準になる。 --- ## 管理者権限については Denoならsudoの部分だけ、外部コマンドとして切り離せば良い --allow-runのパーミッションで行ける! 外部コマンドの実行の部分だけみんなが知っているコマンドにしたら、第三者から見て安全性の確保は容易! --- ## 先ほど課題点二つともクリア! 1. コマンドを実行するのが難しい。 2. 第三者から見た安全性を担保するのが難しい。めっちゃええやん！ --- ## ただ、Denoにも弱点はある --- ## サードパーティのライブラリ少な過ぎ！ --- ## sshクライアントさえない!  --- ## そんなバカな... だって無いんだもん[ssh](https://deno.land/x?query=ssh) --- ## ということでdenoのsshクライアント作ることにしました々色調べて、denoからrustのsshクライアントを使うのが一番楽っぽい。 --- ## しかし、日本語でも英語でも denoからrust、cppの処理を呼ぶのはHello worldレベルの処理しか検索に出てこない。 --- ## 挫けそう... と思っていると.. --- ## その時、天からの声が聞こえました ![天からの](https://hackmd.io/_uploads/SJLdPC61a.jpg =x400) --- ## そこに4つのDenoのソースコードがあるじゃろ？ ![牧師](https://hackmd.io/_uploads/HkNEDCTJa.png =x400) ---- ## わからなくなったら、聖書(Denoのソースコード)に帰る ![聖書](https://hackmd.io/_uploads/r1c6B0a16.png =x400) --- ## Denoで読むべきやつら - Denoland/Deno -> Denoのソースコード(Denoからrustのライブラリ。最新、unstableの検索) - Denoland/deno_std -> Denoの標準ライブラリ(Denoのtsのテスト、モジュールの書き方の参考) - Denoland/deno_core -> Denoのコア部分。型の宣言があったり、いろいろ最低元なもの。 - Denoland/rusty_v8 -> denoで使っているCPPのV8エンジンにパッチ当てて、rustから呼べるようにしたもの --- ## denoland/denoのソースコードを読めば行けそう！ test_ffi配下にrustのソースコードをdenoで読み込んで検査している。  --- ## ffiとはプログラミング言語から、他のプログラミング言語を呼び出すインターフェイス。 denoからrustのソースコードを呼び出すための実装が入っていると思えば良い。 deno/test_ffi配下に書かれているffiのテストがffiとしての細かい仕様になる。 --- ## 最新のdenoでもunstable ただ、最新(v1.37.0)でも、unstableオプションをつける必要がある。  --- ## 公式のソースコード読めばいけそう! --- ## ということでざっくばらんに呼び出し方! --- ## rustの呼び出される側のルール 1. extern "C"と#[no_mangle]をつけた関数経由で呼び出す 2. 使える型はu8, u16, u32, pointer, struct, buffer, boolなど最低限のやつら 3. 文字列は*const u8でbufferとして渡す 4. bufferはDeno側に返さない方が良い。必要ならCのpointerとして返す(rustの未定義動作)  ```rust= #[no_mangle] pub extern "C" fn connect(username: *const u8,username_len: u32, password: *const u8, password_len: u32, addr_octet: u8, addr_octet2: u8, addr_octet3: u8, addr_octet4: u8, port: u16) -> bool{ 実装 } ``` --- ## 以上の関数を作成して rustの動的ライブラリとしてcargoでビルドする。 --- ## deno側の呼び出しルール 1. Deno.dlopenで共有ライブラリを開く 2. 関数名と引数の型を文字列で渡す 3. 構造体を受け取るならDeno側に定義を書く必要がある 4. 構造体や文字列、ポインタをrustから受け取るならバイナリをデコードする必要あり 5. Cのポインタの削除処理 6. 最後に共有ライブラリはclose() ```ts= const downloaded = "rustでビルドした共有ライブラリ" const library = Deno.dlopen(downloaded, { "connect": { name: "connect", parameters: [ // username "buffer", // username_len "u32", // password "buffer", // password_len "u32", // addr_octet "u8", // addr_octet2 "u8", // addr_octet3 "u8", // addr_octet4 "u8", // port "u16" ], result: "bool" }, ``` --- ## 実際動作させてみる docker containerからraspberrypiにあるmiyuuというユーザーにssh経由でechoで語りかけます。  --- ## まとめ Denoは  1. コマンド打つの楽 2. セキュリティ意識高い 3. ライブラリ少ない! 4. rustの資産使えば結構いけそう --- ## ご清聴ありがとうございました仕事頼みたいとか、denoのssh作ったら、使ってみたいという人はフォローよろしくお願いします。 zenn -> ![zenn](https://hackmd.io/_uploads/BkGsCMTgT.png =x300) twitter-> ![twitter](https://hackmd.io/_uploads/Bk8s1QalT.png =x300)  --- ## typescriptがデフォルトだからtypescriptはレガシーでない？因果関係が逆で、microsoftのtypescriptのチームはwebとnodejsの方補完はサポートしているわけじゃないですか。 nodejsのチームがtypescriptの動作を保証しているわけでもサポートしているわけでもないですよね。例えば、あなたがdenoの作者や、rubyの作者ぐらい凄いプログラマーだったとして、javascriptのランタイムを作りました！今作ってちょっとのところです！ typescriptのチームにあなたが作ったランタイムのサポートして欲しいというissueをあなたなり他の人なりが言ったとします。受け入れられますか？受けいられないと思います。なら、どうしますか？自分でtypesciprtのサポートできるようにフォークして、ランタイムがそのモジュール使いますよね？それだけの話で、それをそのまま言うのはやらしいからマーケティング的にどういうか？って言うと、 typescriptをデフォルトでサポートしたランタイムです！って売り出すのがいいですよね？経営的に言うと、新規だとtypescript使うのが普通みたいになっているから、typescriptのサポートしないと事業としてブーストかからないからそうしているってことです。間口は広い方がいいので、 --- ## powershellはとりあえず管理者権限で開いてどういうことかというと、管理者権限 sudo も同じような弱点を持っていて、 sudoに汚染されるこれを防ぐ手段として最近だったら、 OpenBSDのdoas jsの世界にプログラミング言語、ランタイムとしてはDenoが挙げられるように今後なるんじゃないかなと。 typescriptをデフォルトで使うようになったとか、nodejsよりもコマンド打つの楽になった。 --- ## 標準ライブラリは言語ランタイムと切り離されている地味だからか、Denoのすごいところとしてあまりみんな言わないけど、これは丁寧な作りで、例えば、nodejsは標準ライブラリと、言語ランタイムが張り付いているするとどうなるか？ --- ## みんなでDenoのライブラリを書く必要がある特に私に任せて頂けたら、ええお値段で書きますぜ。 --- ## typescriptがデフォルトということ --- ## typescript否定すると  --- ## 1. tsとjsどちらの破壊的な変更の影響を受ける ---- ## typescript細かい仕様が無い細かい仕様がないから、typescriptのコンパイラをrustで書こうという取り組みで難儀してたりする。  --- ## 細かい仕様が無いことの何が困るかみなさんも経験あると思うんですが、 --- ## 気がついたら、ドキュメントと ## tsは本質的にはjsのliterのメタプログラミングなのでそれと役割が似ているやつでうまいこといっている、失敗している言語を探して、それが今どんな結果は現象 ## powershellが適任かなと powershellは本質的にはcsharpのメタプログラミング (一部cppのdllを読んでいる処理もあります。) ## 気がついたら壊れている私が確認しただけでもかなり壊れている、ドキュメント食い違っている処理があって、 1. Set-Acl 2. New-Vm 3. タスクスケジュール周り 4. csvのパース(excel、accessでも無い、ISO基準でも無い特にドキュメントに無い謎のcsvのパース) その他色々  --- ## 実務として、メッセージング、localize周りのclassとか処理だったら、リソースファイルを見て、ソースコードを作成するscaffoldを行う処理とかは規模大きくなったら、考えているやっているところあると思うんですが、それで壊れた処理を生成する可能性がある。 (厳密に言うと最終的にtsのバージョンが上がるとjsにした時に同じコードを吐くことが保証されない)  --- これで選択しないといっても、内部的にはなんか選択しているんでしょ？同じMSのプロジェクトですね。不思議ですね。 --- ## denoはおそらく、typescriptのコンパイラの部分は本体から切り離されて、 deno compilerみたいになって、 denoのバージョンに対応したtypescriptのバージョンでコンパイルするみたいになる denoのバージョンに対してtypescriptのバージョンが張り付いている関数型言語のelm使いたかったらそっち使おうとか。ひょっとしたら、typescritptの悪いところを直したサブセットが今後出る可能性もあるのでそっちの方が良い可能性がある。 --- ## あくまでdenoは言語ランタイム、ビルドなので --- ## パーミッションは安全か？ OSのカーネルランドでその都度ユーザーに対話形式で聞いているわけだから、実行時にユーザーが知らない間に読み書きしない、通信を打たないなどのことを起きないから安全ってことでセキュリティを担保している  --- ## ここら辺はエンジニアの設計スキルの腕の見せ所でこれだけでセキュリティ担保できるということはありえない。あくまでdenoはランタイム時に知らないうちに実行されるのを止めるだけ。 --- ## 1. ユーザーランドからカーネルランドにその操作をやって良いか？という機能と組み合わせる。 -> sudo, doasなど --- ## 動的にバイナリ読み込み？できるよ！ runならいいけど、compileなら埋め込みのほうがいいですよね？  --- ## バイナリをどう呼び出したらいいかわからない。英語でも日本語でもHelloWorld的なwasmの呼び出し方ばっか。 sqliteとかは結構メンテナンスされている感じはあるが、wasmかつcppなので、自分がやりたいものと構成が違う。もうちょっと例が欲しいとかは結構ある。前後の処理が欲しいとか。全体の構成とか。 --- ## whichコマンドの実装としては厳密にはおかしいどこがおかしい？ --- ## カーネルに聞く必要がある実行ファイルとしてOSが認識しているかチェック 1. chmodから見れるパーミッション 2. aclから見れるパーミッション 3. カーネルランドにあるセキュリティframeworkが判断する --- ## セキュリティ的にいいならカーネルはシステム上神様で最終てきにやって良いかはコイツに聞く必要がある。 --- ## whichコマンド [pythonのソースコード](https://github.com/python/cpython/blob/main/Lib/shutil.py) os.access -> osのシステムコール faccessat _exists という設計ヘッダーファイルは /usr/include/unistd.h これらをrustで設計したら良い。 [](https://github.com/rust-lang/libc/blob/main/src/unix/linux_like/linux/mod.rs) --- ##  --- ## Denoの懸念点褒めるところ合ったら、絶対懸念点はある  --- ## ここら辺は個人的な願望とか、そうなるんじゃないかなという個人的な未来予測であることは伝えておきます --- たまに言われるnpmが使えるようになったから、Denoでライブラリが新規作成されるの減るのでは無いか？はあまり懸念点と思っていなくて、nodejsの昔から使われているライブラリは結構中身古くて、そろそろ業界としてもリファクタリングする必要あるかなぁと思うやつが結構あるので、暗号周りとか、システム周りとかに多いから、それらはDenoで書き直す勝ちはあるんじゃないかと。それら参考にDenoのライブラリ書いたらええんじゃ無いかなと。 nodejsで一番使われているライブラリの一つにssh2とかあるんですが、 any型であることを利用して再代入しまくってたり、使われていないswitchがあったり、テストコードが読むのキツかったり、昔は結構ギークな人が個人のス --- ## ないコマンドはDeno.commandという形でサブプロセスとして実行して戻り値とってくるという形もで着るけど、それだとサブプロセスとして実行されたプロセスが何をやっているか？はDenoからは見えないので、ファイルの書き込みしている外部コマンドを --allow-runを認めるとパーミッションのメリットが少なくなる。と言うことはつまり。 ---- --- ## これも一応欠点があって、権限のチェックだけなら良いけど、権限をチェックしてそのまま実行するなと。 [access](https://manpages.ubuntu.com/manpages/impish/ja/man2/access.2.html) denoland/x/plugもちょっとクセある。 “${DENO_DIR}/plug/file” に共有ライブラリのモジュールをキャッシュで持ってしまう。デフォルトだとキャッシュを持ってしまっていて、もし値が変更されてても同じやつを実行してしまうので、 “${DENO_DIR}/plug” にキャッシュを持ってしまっているので、削除する必要がある。ここがリードされるたびにダウンロードさせるのはアレなので、本番はキャッシュされないようにして、開発はキャッシュされないようにする。など。これはdeno本体か、denoland傘下のプロジェクトにあるべきなので、 denoのffiが安定したら、使わなくなる可能性があるのであまり散らばらないように実装する必要がある。 --- ## debianの共有ライブラリを使う postgresqlのクライアントを描いてみる [psycopg](https://www.psycopg.org/install/) インストール先や共有ライブラリの名前を調べる。 [libpg-dev](https://packages.debian.org/search?keywords=libpq-dev) libpg-devを見るとbullseyeを使うのでそれを見る list of files https://packages.debian.org/bullseye/libpq-dev  --- ## 単なるラッパーっぽいので、 libbp.soを参照するだけでよさそう psycopgのソースコードを見て使い方も調べる。 --- ## debug時はキャッシュを持たないようにする。 --- ## 現時点でではstaticなモジュールは呼べないただ、denoでコンパイルして、シングルバイナリを作るという動きに今後なりそう --- ## よくある勢力図 jsランタイムとして三つ巴!戦国時代! nodejs VS Deno VS bun golangとpythonは他言語なのでカヤの外でなくて、 --- ## 実際はこうじゃね？ nodejs VS bun Deno VS golang VS python --- nodejs VS bun -> 速度、キラキラ技術。そのための運用、開発の手間は許容。  Deno VS golang VS python -> システム周り、バッチ処理など堅いことが要求されるもの(差別化点として、denoはV8エンジン、tsの破壊的変更の影響を受ける、golangはgoing my wayで壊さないことに全力投球できる) --- ## 特にDenoの依存関係が独立しているのがシステムプログラム、OS周りの処理としてかなり強そう! pythonはシステム周りのプログラムとして雑にバージョンを上げるのが難しい、 pythonはさくっとかけるので、やったらめったらいろんなもののビルド時依存に使われてている。 nodejsとか  --- golang好きな人はきっとDenoも気にいるはず！ --- ## Deno君、君は意識高いキラキラ陽キャじゃない！ ![](https://hackmd.io/_uploads/SkXp4lfep.png) --- ## 苦難に耐える修行僧か、ただのインテリ陰キャや！ ![修行僧](https://hackmd.io/_uploads/ryiyIgfla.png =x400) ![インテリインキャ](https://hackmd.io/_uploads/ByKgJbGea.png =x400)  --- ## こういうオフラインの会で言うと、新人の可愛いbunちゃんの隣に座りたいかもしれんが、 --- ## 君の隣に座るのはgopher君だ！あ、gopherです。隣座ってもいいですか？ ![](https://hackmd.io/_uploads/S1w_ZWGlT.jpg)  --- ## go君がネットでいくらディスられても同様に 2, 3年後には君もgopher君と同様の鋼のメンタルが要求される。  今のうちに先輩から心得をきておけ。資産が多いnodejsとbunに比べて遅いから中途半端だのディスられる未来が見える。 ![](https://hackmd.io/_uploads/SyoyDCSlp.png =x400) --- ## 俺たちインテリ陰キャ舐めんな！:angry: ![チー牛](https://hackmd.io/_uploads/HJkEexMgp.png =x400)