bash の危険な算術式 - どさにっき
■ bash の危険な算術式 _ 使ってる人がいちばん多いだろうからタイトルでは bash としてるけど、ここで取り上げることは zsh および ksh 一族(本家 ksh、pdksh、mksh)にも該当する。ash、dash などでは該当しない。 _ 以下のシェルスクリプトには脆弱性がある。わかるだろうか。 #!/bin/bash # "品目,単価,個数" の形式の CSV を読んで、"品目,合計金額" の形式で出力する csv="foo.csv" while IFS=, read item price num; do echo "$item,$((price*num))" done < "$csv" これ、細工された CSV ファイルを食わせることで、任意コードの実行ができてしまう。数ある脆弱性の中でもとくにヤバいやつだ。どこが穴なのかというと、タイトルにもあるとおり算術式なのだが、し
Bash: .bashrcと.bash_profileの違いを今度こそ理解する｜TechRacho by BPS株式会社
こんにちは、hachi8833です。社内Slackで見かけたmorimorihogeさんの以下の書き込みで目から鱗が落ちました。 ~/.bashrcで何かを出力してしまうと、rsyncなどのsshパイプで問題が生じることがあるそうです。 参考: 知らないとrsyncでもハマるシェル初期化 - Qiita これをきっかけに、できるかぎり一次情報を元になるべく一般的になるようにまとめてみました。 シェルスクリプト（.bashrcや.bash_profileなども含む）はあまりに自由に書けてしまい、LinuxディストリビューションやmacOSによって作法がまちまちだったりするので、外してはいけないポイントがどこかを知りたかったのでした。 対象はbashとsh（Bourne Shell）に限定します。また、デスクトップGUIの設定ファイルについては最小限にとどめます。 bashのmanページ 元記
Bashの便利な構文だがよく忘れてしまうものの備忘録
Bashでスクリプトを書く場合のポイントをまとめた Bashなどで書くシェルスクリプトは文法がシンプルで覚えると便利。他のプログラム言語だと何行もかかなければならないファイル操作や中身のデータ処理を、ちょちょいと数行レベルで書けとても強力だ。コマンドとの親和性が高い恩恵だろう1。 旧来バッチ処理で本領を発揮するシェルスクリプトだったが、昨今はDocker（Dockerfileや起動スクリプトなど）で活用される機会も多いだろう。 しかしながら他のプログラム言語ではみられない記法があったり、逆に似た書き方もあったりと、混乱しがちなのもシェルスクリプトの特徴かもしれない。 いちいちGoogle先生に確認するのもめんどうなので、このページに整理した2。 主な参照先（よくお世話になっているページ）： UNIXの部屋(68user's page) - http://x68000.q-e-d.net/~
雰囲気でシェルを使っている人のためのシェル入門 | κeenのHappy Hacκing Blog
κeenです。雰囲気でシェルを使ってる人が多いとのことだったので少しばかり込み入った知識を。 あと一応POSIX準拠かどうかも気にしながらやっていきます。 基礎知識編 シェルの種類 まず、POSIXにシェルが定義されています。 これに最低限の機能で準拠しているものをPOSIXシェルと呼ぶことにします。いわゆる/bin/shです。具体的な実装はbsh、ash、dashあたりでしょうか。 最低限の機能以上に色々拡張されているシェルを拡張POSIXシェルと呼ぶことにします。具体的な実装はbash、zsh、kshなどでしょうか。 ここでは触れませんがPOSIX準拠でないシェルも存在してcshやtcshなどのシェルがあります。あと確か最近話題のfishも違ったような。 さて、1つ問題になるのは普段使いのコマンドラインはおおむね拡張POSIXシェルでしょうが、サーバで使うシェルやデプロイスクリプトで呼
bashのpipefailで確実にスクリプトを止める – 上田ブログ
シェルプログラミング実用テクニック、出版される前からもう補足ですが、私めがbashのpipefailというオプションをすっかり見落としていたのでフォローしておきます。 カンニング先: パイプの途中のエラーを取る | 揮発性のメモ 本文ではbashに-e（エラーがあったら止める）をつけてもパイプラインの左側のコマンドにエラーがあったときに処理が止まらないと書きました。 例です。 ###false | true###でfalseが終了ステータス1を返すが・・・### uedambp:~ ueda$ cat hoge.bash #!/bin/bash -e false | true echo do not stop ###-eがあるにもかかわらずechoが実行される### uedambp:~ ueda$ ./hoge.bash do not stop が、次のようにpipefailというオプショ
bashの組込みコマンド自作によるスクリプトの高速化 - Qiita
はじめに bashには次の2つの理由によって、組み込みコマンド(builtin command)というものが存在します。 スクリプトの高速化のため。組み込みコマンドであれば通常のコマンドを実行する場合に比べてプロセスの生成コスト(fork()/exec())が削減できる bash自身の状態を変更させるため。例えばcdコマンドを/bin/cdとして用意してbashから当該コマンドを実行しても、当該コマンドのpwdが変更されるだけで、bashのそれは変更されないため、意味がない 今回は前者に焦点を合わせて、その効果と、組み込みコマンドの自作方法について述べます。 予備知識: 組込みコマンドによるスクリプト高速化の効果 組込みコマンドそのものの存在、及びその存在意義について既にご存知のかたは、この節を飛ばしてもらって構いません。 例えば皆さんがbashスクリプトからechoコマンドを実行した場合
bash の脆弱性 "Shell Shock" のめっちゃ細かい話 その2 (CVE-2014-7169) - もろず blog
※2014/10/3 0:00時点で Shell Shock への修正パッチは4つ公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください ※2014/10/7 14:00時点で Shell Shock への修正パッチは6個公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください 先日 ShellShock についての記事を書きましたが、 その後もいろいろと進展があり更にいくつかの脆弱性が検出されました ※前回の記事はコチラ bash の脆弱性 "Shell Shock" のめっちゃ細かい話 (CVE-2014-6271) - もろず blog 現時点で ShellShock に関わる脆弱性はなんと6個も報告されています CVE-2014-6271 CVE-2014-6277 CVE-2014-6278 CVE-2014-7169 CVE-2
シェルの展開順序に気をつけよう - Qiita
Shell Script Advent Calendar 2016の12月17日エントリーです（途中途切れてるので日数計算は不明）。 初級者向けの基礎知識として、シェルの展開順序について書きます。ここではbashを例に説明しますが、基本は各種シェルに共通していると思います。 展開と実行の順序 端末やシェルスクリプトなどでシェルを使うときには、展開順序を意識していないと思わぬ失敗をすることがあります。展開（expansion）とは、ファイル名のパターン（ワイルドカード）やシェル変数などの処理です。 展開のメカニズムは普通のプログラミング言語のモデルと大きく異なる点の一つです。たとえば、多くのプログラミング言語の文法では変数は値の一種として扱われますが、シェルの文法では変数が展開されてから実際の処理が実行されます。このあたりの感覚は、C言語のプリプロセッサマクロなどに近いかもしれません。 ba
シェルスクリプト——こんなとき、かうする - Qiita
POSIX シェルの小ネタ集。随時更新。 POSIX の範囲外の機能に依存するところには 【non-POSIX】 と書いておいた。 ファイル操作 空のファイルを作る touch でもいいがリダイレクトした方が速い。 >> filename # 既存ファイルは上書きしない (ファイルの更新日時も変へない) >| filename # 既存ファイルは空にする > filename # -C が有効なら既存ファイルがあるとエラーになる フィルタ ソートして重複行を消す sort | uniq でもいいが sort -u だと一コマンドで済む。 ソートせずに重複行を消す awk '!x[$0]++' 1 行番号を付加する awk '{print ++i,$0}' 【non-POSIX】 cat -n 一行目だけを消す tail -n +2 sed 1d 最後の行だけを消す head -n -1 s
シェルスクリプトの罠を避ける三つの tips
シェルスクリプトは、Unix 系環境で仕事をするエンジニアなら誰もが一度は書くであろうにもかかわらず、書き方や特性を熟知している人が少ない言語です。この記事は、シェルスクリプトを書くときに罠を踏まないようにするために最低限あなたが気を付けるべき tips 集です。「たかがシェルスクリプト」とは思わないでください。生半可に書かれたシェルスクリプトはあなたの (チームの) 生産性をかえって低下させます。 Shebang に bash を明示しろ Bash でしか使えない機能のことを俗に Bashism と言います。Bashism はもちろん Bash 以外のシェルでは動きません。これに関するありがちな罠は、以下のように発生します。 Bash が /bin/sh として使われている環境でシェルスクリプトを書く。うっかり Bashism がシェルスクリプトに含まれていても、 /bin/sh は何も
Googleの肩に乗ってShellコーディングしちゃおう - Qiita
はじめに GoogleさんがShellスタイルガイドを共有していたので、いくつか気になった点をピックアップしました。 自分のShellスタイルはかなり我流なので、自省の意味も込めてコメントも併記します。 Googleスタイルガイドの元ネタ （Python/C++/Java/Rとかだけでなくdocumentガイドなど色々あります） https://github.com/google/styleguide Shellスタイルガイド （今回はこちら） http://google.github.io/styleguide/shell.xml 本当は人間がチェックするのではなくcpplintのためXML定義なのかもですが、気にしない気にしない。 （見たところcpplintはc++だけだと思ってます） commitフックでshell系のlint走らせろっていうのが今風なのかもしれませんが、キニシナイキ
シェルスクリプトの書き方
12月にTwitterに流れていたPOSIX何とかという話題を読んでいたらこの記事にたどり着いた。もう3年以上前の記事だけれど、内容がとても偏っていると思う。 シェルスクリプトの書き方について解説しているウェブ上の資料は少なく、当該記事も検索に引っかかりやすい。最近の初学者はまず検索して調べることが多いが、反論が検索に引っかからないとそれが正しいと受け入れてしまう可能性が高いように思う。きちんと反論している日本語の記事が引っかからないので、あえて問題と思う点をまとめてみた。 そんなこと書いているあなたは誰? わたしはシェルスクリプトの専門家でも職業プログラマでもないけれど、シェルスクリプトを書いた量はそれなりにあると思う。環境はSunOS4, Solaris, HP-UX, IBM AIX, FreeBSD, OpenBSD, Linuxを経験していて、移植性や性能の問題がどこで発生しやす
bashを読もう！『オープンソースアプリケーションのアーキテクチャ』3.1〜3.3 | DevelopersIO
こんにちは、虎塚です。 8月31日(日)に「オープンソースアプリケーションのアーキテクチャ読書会(1)」という勉強会に参加してきました。 とても面白い本だったので、3章の3.1〜3.2の内容をレポートしたいと思います。 The Architecture of Open Source Applications 日本語版PDF はじめに 読書会の開催経緯 主催者の方がある経緯でSQLiteのソースコードを読もうとしたところ、想定したより巨大だったので、先にBarkeley DBを読むことにしたそうです。 Barkeley DBの資料を探す中で、この本『Architecture of Open Source Applications』に辿り着き、せっかくなので他にも面白そうな章を読んでみようということで、今回の読書会が企画されたとのことです。 読書会の進行 20人ほどの参加者を席順に従って2人ず
bash - コマンド (プログラム) の説明 - Linux コマンド集 一覧表
bash は、標準入力やファイルから読み込んだコマンドを実行する、 sh 互換のコマンド言語インタプリタです。 bash には、Korn シェルや C シェル (ksh や csh ) の便利な機能も採り入れられています。 bash は IEEE POSIX Shell and Tools specification (IEEE Working Group 10032) に準拠する実装を目指しています。 bash は以下のオプションを起動時に解釈します (組み込みコマンド set の説明で述べられている 1 文字のシェルオプションも使えます): -c string -c オプションが指定されると、コマンドが string から読み込まれます。 string の後に引き数があれば、これらは 位置パラメータ (positional parameter: $0 からはじまるパラメータ) に代入さ
コマンドラインツールを書くなら知っておきたい Bash の 予約済み Exit Code - Qiita
上記の表の通り，Exit Code 1, 2, 126〜165, 255 は特別な意味を持ち，スクリプトやプログラム内で exit に指定するパラメータとしては避けるべきである．とりわけ，Exit Code 127 はトラブルシューティングで混乱の元である（"command not found" で終了したのか，プログラム固有のエラーなのか区別できなくなる）．しかしながら，多くのスクリプトが exit 1 を一般的な実行を続行できないエラーとして使っている．Exit Code 1 は Bash の一般的なエラーを含め，とても多くのエラーで発生しうるので，デバッグの時に切り分けが大変になるだろう． Exit Code を体系立てて定義する試みはある（/usr/include/sysexits.h）が，これは C と C++ プログラマー向けである．スクリプトに関しても同様な感じにするのが適切
シェルスクリプトでパスワード入力プロンプト - Qiita
ユーザーにパスワードを入力してもらうシェルスクリプトを作成していたら bash の read コマンドに便利なオプションがあったのでメモ。 入力プロンプトに "Password:" と表示するには -p が使えます。 入力元が端末のときのみプロンプトを表示するという賢いオプションです。 -p prompt Display prompt on standard error, without a trailing new- line, before attempting to read any input. The prompt is displayed only if input is coming from a terminal.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Learning the bash Shell, Second Edition
https://cmdchallenge.com/
オープンソースのアーキテクチャ(和訳)
5. bash — it-note 1.0 ドキュメント