2011-03-01 :-(
_ 午後
1300 実機
_ 夜やる暇がないならば朝やればいいじゃない
定時退勤してたときは帰宅後 録画しておいたアニメを見ながら筋トレ( ref. アニメダイエット ) してたんだが最近は帰宅後にそーいう時間を作れないので朝やってる。
平日の夜 23 時ころからの NHK 総合 Bizスポ を録画しておき、翌日朝は 1.5 倍速で再生しながら Biz 部だけ(スポーツ部は興味ないので見てない)見ながら筋トレ。これで 10 分くらい。毎日 10 分くらいの筋トレ時間でる。
ただし今度はアニメを見てる暇がないので録画したアニメが溜まってしまう。
_ [NetBSD][systrace][翻訳]Systrace Policies - O'Reilly Media
Systrace ポリシー
by Michael W. Lucas
01/30/2003
One of the more exciting new features in NetBSD and OpenBSD is systrace(1), a system call access manager. With systrace, a system administrator can say which system calls can be made by which programs and how those calls can be made. Proper use of systrace can greatly reduce the risks inherent in running poorly-written or exploitable programs. systrace policies can confine users in a manner completely independent of Unix permissions. You can even define the errors that the system calls return when access is denied, to allow programs to fail in a more proper manner. Proper use of systrace requires a practical understanding of system calls, what programs must have to work properly, and how these things interact with security.
NetBSD と OpenBSD のより興奮する機能の 1 つは、システムコールアクセスマネージャー systrace(1) だ。systrace を使うと、システム管理者はプログラムから呼び出されるシステムコールと、それがどのように呼び出されるかを見ることができる。systrace は、ダサいコーディングだったり脆弱性があるプログラムに潜むリスクを軽減するために使うととてもよい。systrace の方針は、Unix のパーミッションに完全に依存したユーザー制限をするようになっている。システムコールが「アクセスが拒否された」というエラーを返させるようにするには、より適切な方法でプログラムが失敗するようにすればよい。systrace を使うときは、実際のシステムコールを理解し、プログラムを正しく動作させず、セキュリティにどう影響するのかを把握しておかなければならない。
First off, what are system calls? Sysadmins fling that term around a lot, but many of them don't know exactly what it means. A system call is a function that lets you talk to the operating system kernel. If you want to allocate memory, open a TCP/IP port, or perform input/output on the disk, that's a system call. System calls are documented in section 2 of the online manual.
まず、システムコールとはなんぞや? システム管理者たちはよくこの言葉を使うが、彼らのうち意味をちゃんと知っているものはほとんど居ない。システムコールとは、オペレーティングシステムのカーネルと会話するときに使うものだ。メモリを確保したいとき、TCP/IP ポートを開きたいとき、ディスクの入出力をしたいときに使う。それがシステムコールだ。システムコールの文書はオンラインマニュアルのセクション 2 にある。
Unix also supports a wide variety of C library calls. These are often confused with system calls but are actually just standardized routines for things that could be written within a program. You could easily write a function to compute square roots within a program, for example, but you could not write a function to allocate memory without using a system call. If you're in doubt whether a particular function is a system call or a C library function, check the online manual.
Unix は多様な C ライブラリコールにも対応している。これらはたまにシステムコールとごっちゃにされるが、これはプログラムの範囲内で使われるためのたんなる標準関数である。平方根を計算する関数は簡単に書けるが、たとえばメモリを確保する処理はシステムコールを使わずに書くことはできない。システムコールを使うにせよ、C ライブラリ関数を使うにせよオンラインマニュアルを読むこと。
You may find an occasional system call that is not documented in the online manual, such as break(). You'll need to dig into other resources to identify these calls. (break() in particular is a very old system call used within libc, but not by programmers, so it seems to have escaped being documented in the man pages.)
break() のように、たまにオンラインマニュアルに存在しないシステムコールを見かけるかもしれない。こういったシステムコールについては別の文書を参照する( break() はプログラマ向けではなく、libc で使われていたとても古いシステムコールである。なので man ページから削除された )。
systrace denies all actions that are not explicitly permitted and logs the rejection to syslog. If a program running under systrace has a problem, you can find out what system call the program wants and decide if you want to add it to your policy, reconfigure the program, or live with the error.
systrace の動作は不明確な権限で制限されており、ログを syslog に書けない。systrace の下で走っているプログラムに問題が発生したら、プログラムが使おうとしているシステムコールを調べ、必要であればポリシーに追加し、プログラムを設定しなおすか、エラーを放置しておく。
systrace has several important pieces: policies, the policy generation tools, the runtime access management tool, and the sysadmin real-time interface. This article gives a brief overview of policies. Next time, we'll learn about the systrace tools.
systrace はいくつか重要な事項がある。ポリシー、ポリシー生成ツール、実行時アクセス制御ツール、そしてシステム管理者向けリアルタイムインターフェースだ。ここではポリシーの概要を説明する。次回に systrace ツールについて学ぶ。
Reading systrace Policies (systrace ポリシーを読む)
The systrace(1) manual page includes a full description of the syntax used for policy descriptions, but I generally find it easier to look at some examples of a working policy and then go over the syntax in detail. Since named has been a subject of recent security discussions, let's look at the policy that OpenBSD 3.2 provides for named.
systrace(1) マニュアルページはポリシーを使う上での構文の全説明が載っている。ポリシーを運営するためのサンプルが簡単に見つかるし、構文の詳細も分かる。named の最近のセキュリティー議論については、 OpenBSD 3.2 の named のポリシーを参照。
Before reviewing the named policy, let's review some commonly-known facts about the name server daemon's system access requirements. Zone transfers occur on port 53/TCP, while basic lookup services are provided on port 53/UDP. OpenBSD chroots named into /var/named by default and logs everything to /var/log/messages. We might expect system calls to allow this access.
named のポリシーを読む前に、ネームサーバーデーモンが要求するアクセスについて一般的な状況を読もう。ゾーン転送は 53/TCP で使い、基本的な名前解決サービスは 53/UDP を使う。OpenBSD では named は既定で /var/named に chroot し、すべてのログは /var/log/messages に書かれる。これらにアクセスするシステムコールを許可すればよい。
Each systrace policy file is in a file named after the full path of the program, replacing slashes with underscores. The policy file usr_sbin_named contains quite a few entries that allow access beyond this, however. The file starts with:
systrace ポリシーのファイルは named のフルパス( スラッシュはアンダースコアに置換する )のあとに繋げられる。usr_sbin_named ポリシーファイルには以下のようにいくつかのエントリーを含む。ファイルの冒頭はこう。
# Policy for named that uses named user and chroots to /var/named # This policy works for the default configuration of named. Policy: /usr/sbin/named, Emulation: native
The "Policy" statement gives the full path to the program this policy is for. You can't fool systrace(1) by giving the same name to a program elsewhere on the system. The "Emulation" entry shows which ABI this policy is for. Remember, BSD systems expose ABIs for a variety of operating systems. systrace can theoretically manage system call access for any ABI, although only native and Linux binaries are supported at the moment.
Policy 文はこのポリシーで扱うプログラムへのフルパスを書く。システムの別のところに同じ名前のプログラムがある、なんてことはないように。Emulation エントリーはこのポリシーの ABI を意味する。BSD システムには様々な ABI があることを忘れないように。systrace は理論上はあらゆる ABI へアクセスするシステムコールを制御できるのだが、ネイティブだけであり、Linux バイナリ対応はもう少しかかる。
The remaining lines define a variety of system calls that the program may or may not use. The sample policy for named includes 73 lines of system call rules. The most basic look like this.
remaining 行はプログラムが使用するか、または使用しそうなシステムコールを定義する。named のサンプルポリシーでは 73 行のシステムコールの規則がある。最も基本的なものは以下のようになる。
native-accept: permit
When /usr/sbin/named tries to use the accept() system call, under the native ABI, it is allowed. What is accept()? Run man 2 accept and you'll see that this accepts connections on a socket. A nameserver will obviously have to accept connections on a network socket!
/usr/sbin/named がネイティブ ABI の下で accept() システムコールを使おうとしたときは許可される。accept() って? man 2 accept を実行すれば、これは socket 接続を受け入れるものだということが分かる。ネームサーバーがネットワークソケットの接続を受け入れることは明らかだからだ。
Other rules are far more restrictive. Here's a rule for bind(), the system call that lets a program request a TCP/IP port to attach to.
他にも制限するルールがある。bind() のルールだ。bind() はプログラムからの TCP/IP ポートへのリクエストをアタッチするシステムコールだ。
native-bind: sockaddr match "inet-*:53" then permit
sockaddr is the name of an argument taken by the accept() system call. The fnmatch keyword tells systrace to compare the given variable with the string inet-*:53, according to the standard shell pattern-matching (globbing) rules. So, if the variable sockaddr matches the string inet-*:53, the connection is accepted. This program can bind to port 53, over both TCP and UDP protocols. If an attacker had an exploit to make named(8) attach a command prompt on a high-numbered port, this systrace policy would prevent that exploit from working -- without changing a single line of named(8) code!
sockaddr は accept() システムコールに渡す引数の名前である。fnmatch は、systrace に渡された変数名と inet-*:53 という文字列を比較する。標準シェルのパターンマッチ (globbing) のルールどおりのものだ。つまり、sockaddr 変数が inet-*:53 文字列にマッチしたら、接続は許可される。このプログラムはポート 53 に bind でき、TCP と UDP の両方を扱える。攻撃者が、大きいポート番号を使うようにした named(8) を使ってコマンドプロンプトから攻撃をしてきた場合、この systrace ポリシーは named(8) を 1 行も変えることなく攻撃を防ぐのだ!
native-chdir: filename eq "/" then permit native-chdir: filename eq "/namedb" then permit
At first glance, this seem wrong. The eq keyword compares one string to another and requires an exact match. If the program tries to go to the root directory, or to the directory /namedb, systrace will allow it. Why would you possibly want to allow named to access to the root directory, however? The next entry explains why.
一見するとこれは失敗するように見える。eq キーワードは 1 文字と厳密に比較する。プログラムがルートディレクトリや、/namedb ディレクトリに行こうとすると、systrace は許可するだろう。なぜ named によるルートディレクトリアクセスを許可するのかって? これから説明しよう。
native-chroot: filename eq "/var/named" then permit
We can use the native chroot() system call to change our root directory to /var/named, but to no other directory. At this point, the /namedb directory is actually /var/named/namedb, which is a sensible location for a chrooted named(8) to access. We also know that named(8) logs to /var/log/messages, however. How does that work, if the program is chrooted to /var/named?
ルートディレクトリを /var/named に限定するためにネイティブの chroot() システムコールを使う。ここで、/namedb ディレクトリは実は /var/named/namedb である。chroot された named(8) は、これでもうまくアクセスできるのである。また、named(8) のログは /var/log/messages に吐かれるわけだが、プログラムが /var/named に chroot した場合にこれがどう動作するのだろうか?
native-connect: sockaddr eq "/dev/log" then permit
This program can use the native connect(2) system call to talk to /dev/log and only /dev/log. That device hands the connections off elsewhere. If you didn't know that this was how the program logged, however, you'd be confused. Although the program is running in a changed root, /dev/log is opened before the chroot happens and chroot(2) does not revoke access to open files outside the chrooted area.
プログラムで使うネイティブの connect(2) システムコールは、 /dev/log とだけ通信できる。このデバイスはどこにも接続されていない。プログラムがどうやってログするのか分からないと混乱するだろう。プログラムは変更した root で走っているわけだが、/dev/log は chroot される前に開かれ、そして chroot(2) は chroot 外で開かれたファイルへのアクセスを拒否しないのである。
We'll also see some entries for system calls that do not exist.
システムコールが存在しない場合についても見てみよう。
native-fsread: filename eq "/" then permit native-fsread: filename eq "/dev/arandom" then permit native-fsread: filename eq "/etc/group" then permit
systrace aliases certain system calls with very similar functions into groups. You can disable this functionality with a command-line switch and only use the exact system calls you specify, but in most cases these aliases are quite useful and shrink your policies considerably. The two aliases are fsread and fswrite. fsread is an alias for stat(), lstat(), readlink(), and access(), under the native and Linux ABIs. fswrite is an alias for unlink(), mkdir(), and rmdir(), in both the native and Linux ABIs. As open() can be used to either read or write a file, it is aliased by both fsread and fswrite depending on how it is called. So named(8) can read certain /etc files, it can list the contents of the root directory, and it can access the groups file.
systrace は、グループの中 { /etc/group か??? }の関数で共通していると思われるシステムコールがあると別名を作る。この機能はコマンドラインスイッチで無効にでき、明記しておいたシステムコールにだけ適用される。これらの別名はけっこう有用で、ポリシーを削減するのに役立つ。fsread と fswrite という 2 つの別名がある。fsread は、ネイティブな Linux ABI における stat()、lstat()、readlink()、access() の別名である。fswrite は、unlink()、mkdir()、そして rmdir() の別名であり、双方ともネイティブの Linux ABI である。open() のように、ファイルの読み書き両方に使えるものは、fsread と fswrite の両方に別名が作られ、呼ばれた方法によってどちらが使われるのか決まる。だから named(8) は /etc のファイルを読めるし、ルートディレクトリ以下の内容を列挙できるし、 groups ファイルにアクセスできるのである。
systrace supports two optional keywords at the end of a policy statement, errorcode and log.
systrace は、ポリシーの文の末尾の errorcode と log というキーワードに対応している。
The errorcode is the error that is returned when the program attempts to access this system call. Programs will behave differently depending on the error that they receive; named will react differently to a "permission denied" error than it will to an "out of memory" error. You can get a complete list of error codes from errno(2). Use the error name, not the error number. For example, here we return an error for non-existent files.
errorcode はプログラムがシステムコールにアクセスしたときに返すエラーである。プログラムは、受け取ったエラーによって挙動が変わる。named は "permission denied" エラーを受け取ったときと、"out of memory" エラーを受け取ったときでは挙動が異なるのである。完全なエラーコードの一覧は errono(2) で得られる。エラー番号ではなく、エラー名を使いなさい。たとえばファイルが存在しないときのエラーの戻り値など。
filename sub "<non-existent filename>" then deny[enoent]
If you put the word log at the end of your rule, successful system calls will be logged. For example, if we wanted to log each time named(8) attached to port 53, we could edit the policy statement for the bind() call to read:
ルールの末尾に log という単語を書いておけばシステムコールが成功したときにログが書かれる。たとえば、named(8) が ポート 53 を使うたびにログするには、bind() のポリシー文を編集すればよい
native-bind: sockaddr match "inet-*:53" then permit log
You can also choose to filter rules based on user ID and group ID, as the example here demonstrates.
また、ユーザーID とグループID をもとにしたフィルタルールを使うこともできる。たとえばこう。
native-setgid: gid eq "70" then permit
This very brief overview covers the vast majority of the rules you will see. As in so many things in computing, systrace does 90% of its work with 10% of its features. For full details on the systrace grammar, read systrace(1). Now that you can recognize a systrace policy when you see one, next time we'll look at some of the tools you can use to create your own policies.
ここでは膨大なルールのうちごく一部を示した。コンピューティングの世界の様々な事柄についても、systrace は、その持つ機能のうち 10% だけが使われ、さらにそのうち 90% が機能している。systrace の全ての文法を知るには systrace(1) を読むとよい。見たいものがあればそこで見ることができる。我々が今度 会うときは、あなた自身のポリシーを作成したときになるだろう。
Michael W. Lucas
2011-03-03 :-(
2011-03-04 :-)
_ 夜
1800 南武会
_ [南武会]南武会 vol.12
ヴァンプ将軍の鶏団子鍋食べようぜということで集合した。( ref. 川崎市高津区役所 -「天体戦士サンレッド」と連携した区セールス事業 )
どうやら彼らの仕事場にはミサワが居るようだ ( ref. 地獄のミサワの「女に惚れさす名言集」 )
2011-03-05 :-)
_ [Java]Javaプログラマであるかを見分ける10の質問 - やさしいデスマーチ
Java は 7 年くらい前に結城浩さんの本を写経したことくらいしかないので結論をいうと「知らない」になるんだが、せっかくだから想像力を働かせて勘でやってみた。
1. ==演算子とequalsメソッドの違いは何か？
値が同じかどうか、オブジェクトが同じかどうか
2. 文字列の連結は原則として+演算子を使ってはならない理由を説明せよ。
+ 演算子の左右でその都度 文字列オブジェクトが生成されるから
3. List<Integer>のようにジェネリクス型を使う主たる目的は何か？
コンパイル時に型をチェックするため( 実行時じゃないよね? )
4. オブジェクトがガベージコレクション（GC）される主たる条件は何か？
メモリが必要になったとき
5. チェック例外と非チェック例外の違いを型と例外処理の観点で説明せよ。
知らない
6. フィールドのアクセス修飾子をprivateにしgetter/setterメソッドを提供する事でフィールドを参照する設計方針を取る主な理由を説明せよ
カプセル化のため
7. NullPointerExceptionが発生するのは主にどういう状況か？
知らない
8. オーバーロードとオーバーライドの違いは何か？
うお。知らない
9. コンストラクタとは何か？
オブジェクトが生成されるときの処理
10. インターフェイスを利用する目的を１つ説明せよ
多態性を利用するため
ところで
受託業務を中心にしている弊社は、Javaで業務系ウェブアプリケーションの開発を行う事になりました。しかし社内のリソースを使うにも１－２名足らない事が見積もりから解っています。そこで、中堅エンジニアを1－2名募集することになりました。正社員か派遣かは問いませんが、経験が３年程度の中堅プログラマが必要です。同等またはそれ以上のスキルを持つ正社員がプロジェクトを牽引しますが、ゼロから教えながら教育することはできないので、必要最低限のスキルを持っていることが条件になります。
というのであれば Java 認定資格 を持ってるか否かを問うたほうが手っ取り早いんじゃないか。
4797325151
2011-03-06 :-)
2011-03-07 :-)
_ [eyevio][tdiary]eyevio の tdiary プラグインを書いてみた
定型文を返すだけなんだけど
#
# eyevio.rb: eyevio plugin for tDiary
#
# Copyright (C) 2011 by Susumu Miwa miwarin@gmail.com
#
# usage: <%= eyevio 'movie_id'[, size] %>
#
#
def eyevio( movie_id, size = 'large' )
sizelist = {}
sizelist[ 'large' ] = { :width => 521, :height => 330 }
sizelist[ 'medium' ] = { :width => 391, :height => 248 }
sizelist[ 'small' ] = { :width => 261, :height => 165 }
size = 'large' unless sizelist.key?( size )
width = sizelist[ size ][ :width ]
height = sizelist[ size ][ :height ]
%Q[<iframe src="http://eyevio.jp/embed.do?movieId=#{movie_id}&width=#{width}&height=#{height}" style="margin: 0px; width: #{width}px; height: #{height}px;" frameborder="0" scrolling="no"><a href="http://eyevio.jp/movie/#{movie_id}"><img src="http://eyevio.jp/file/#{movie_id}/w1" /></a></iframe>]
end
_ Before You Reach For Love が GT5 のカートレースにすごくよく合う
この曲は巡航速度 400km/h のリッジレーサー7 カテゴリー1 で使うよりも 130km/h くらいのほうがしっくりくるのだな。
_ ,
というのが書きたかっただけ
2011-03-08 :-(
_ 午後
1330 レーザー教育
_ [NetBSD][chroot][翻訳][ntp]chrooted ntpd in NetBSD - O'Reilly Media
NetBSD で chroot な ntpd (1)
by Emmanuel Dreyfus
02/13/2003
chrooting ntpd ( ntpd を chroot する )
As we explained in Securing Systems with chroot, Part One, a daemon must run with an unprivileged user ID (UID) in order to be safely chrooted. This is a problem, since many daemons need some superuser privileges in order to operate. In some situations, superuser privileges are only necessary during initialization, and it is possible to switch to an unprivileged UID later. This is the case for named, the Domain Name System (DNS) server from the Internet Software Consortium (ISC). named needs superuser privileges in order to bind to UDP port 53 (superuser privileges are needed on almost all Unix systems to bind to ports lower than 1024). Once this is done, named is able to chroot to a directory where the zone files are stored, and it can operate under an unprivileged UID, typically the user named.
第一部では、chroot でのセキュアシステムについて説明しよう。安全に chroot するためにデーモンは非特権ユーザー ID で動作させなくてはならない。ここで問題がある。多くのデーモンは、動作するためにスーパーユーザー特権が必要なのである。いくつかのデーモンは、スーパーユーザー特権が必要なのは初期化時だけであり、以降は非特権ユーザーIDに切り替えて動作させることができる。ここでは named( the Internet Software Consortium (ISC) によるドメインネームシステム(DNS)サーバー )を扱う。named は UDP ポート 53 に bind するときにスーパーユーザー特権が必要になる( ほとんどすべての Unix では 1024 以下のポート番号に bind するためにはスーパーユーザー特権が必要になる )。これにより、named はゾーンファイルの設置ディレクトリに chroot 出来るようになり、非特権ユーザーID ( named ユーザーが一般的 )で操作できるようになる。
ntpd needs superuser privileges for two operations: binding to UDP port 123 (at initialization time) and using time control system calls such as adjtime(2) and ntp_adjtime(2), which are restricted to the superuser.
ntpd は、スーパーユーザー特権が必要な操作が 2 つある。初期化時に UDP ポート 123 に bind することと、時刻制御のために adjtime(2) と ntp_adjtime(2) システムコールを呼ぶことだ。これらはスーパーユーザーでなければならない。
For the first operation, we could proceed as named does, first binding to UDP port 123, then calling chroot(2) and setuid(2). The problem is the second operation. To be able to chroot ntpd after initialization, we need a way to enable an unprivileged user to control the system clock. Such a feature was introduced in NetBSD 1.6, with the clockctl device.
第一の操作としては、named を UDP ポート 123 に bind させ、そして chroot(2) と setuid(2) する。問題は、第二の操作だ。ntpd の初期化後に chroot させ、非特権ユーザーでシステムクロックを制御させるようにせねばならない。これには NetBSD 1.6 では clockctl デバイスを使える。
The clockctl device ( clockctl デバイス )
On NetBSD, the system clock can be affected through four different system calls: adjtime(2), settimeofday(2), clock_settime(2), and ntp_adjtime(2), the last available only if the kernel was compiled with the NTP option.
NetBSD にはシステムクロックに影響するシステムコールが 4 つある。adjtime(2)、settimeofday(2)、clock_settime(2)、そして ntp_adjtime(2) だ。ntp_adjtime(2) はカーネルを NTP オプション付きでコンパイルしておく必要がある。
The clockctl device introduces alternative entry points to these system calls, through a special device file typically named /dev/clockctl. The alternative entry points are done through ioctl(2) system calls on the device file. ioctl(2) is a general purpose system call that enables the user to perform a custom action on a file object. We will see this in more depth in the next part of this article.
clockctl デバイスは、これらのシステムコールを使うための別のエントリーポイントを提供する。スペシャルデバイスファイルは、たいてい /dev/clockctl という名前である。このエントリーポイントによって、ioctl(2) システムコールでデバイスファイルを操作するのと同じことができる。ioctl(2) は、一般的には、ユーザーがファイルオブジェクトへの独自操作を有効にするためのシステムコールである。次の章でさらに詳しく見ていく。
If a user has write access to /dev/clockctl, then he can use the alternative entry points and can control the system clock. In order to chroot ntpd, we therefore just need to build a kernel with the clockctl device driver and ensure that the unprivileged user under which ntpd is running in the chroot jail has write access to /dev/clockctl.
ユーザーが /dev/clockctl に書き込むと、エントリーポイントを使えるようになり、 システムクロックを制御できるようになる。ntpd を chroot するために、clockctl デバイスを有効にしてカーネルをビルドし、chroot jail で非特権ユーザーで ntpd を走らせ、 /dev/clockctl に書き込ませるようにする。
In order to be administrator-friendly, NetBSD 1.6 comes with clockctl enabled in GENERIC kernels--the /dev/clockctl file is installed by default, and the startup scripts already know about clockctl. Therefore, the system administrator just has to add one line to /etc/rc.conf. Here are the relevant lines from /etc/defaults/rc.conf:
システム管理者に朗報。NetBSD 1.6 では GENERIC カーネルで clockctl が有効になっており、デフォルトで /dev/clockctl ファイルが作られ、clockctl のスタートアップスクリプトも入る。システム管理者は /etc/rc.conf に 1 行追加するだけだ。/etc/defaults/rc.conf には以下のように書いてある。
# To run the ntpd(8) NTP server as an unprivileged user under a # chroot(2) cage, uncomment the following, after ensuring that: # - The kernel has "pseudo-device clockctl" compiled in # - /dev/clockctl is present # #ntpd_chrootdir="/var/chroot/ntpd"
The next part of this article is more developer-oriented. It deals with the implementation details of the chrooted ntpd. In the next two sections, we will focus on the userland modifications that were required in order to provide a chrootable ntpd, and we will discuss the implementation details of the clockctl device driver.
次の文書では開発者向けの説明をする。chroot された ntpd の実装の詳細について議論する。次の 2 つの章で ntpd を chroot するためにユーザーランドで必要な変更について具体的に見ていき、clockctl デバイスドライバを実装するための詳細を議論する。
Userland Modifications: libc (ユーザーランドの変更: libc)
Our goal was to make modifications as minor as possible in the NTP daemon. We especially did not want to introduce a new Application Programming Interface (API). This goal was achieved at the expense of introducing some magic into NetBSD's libc.
ここでは、NTP デーモンを変更することをゴールとする。新しいアプリケーションプログラミングインターフェース (API) を知る必要はない。NetBSD の libc の黒魔術に集約されている。
When a user program is built, each system call is turned into a library call to a function in the libc known as the system call stub. The function does the actual system call, and may do some additional handling for backward compatibility. The stubs that do more than just the system call have a C source file associated with them. They are listed in the SRC variable in src/lib/libc/sys/Makefile.inc. For an example of a system call stub that does additional handling, see src/lib/libc/sys/lseek.c.
ユーザープログラムをビルドするとき、各システムコールは、システムコールをスタブした libc 内の関数を呼ぶ形になる。関数は実際のシステムコールを呼び、上位互換性のためにいくつかハンドルを追加する。スタブは、C ソースファイルからたんにシステムコールを呼ぶだけよりも多くのことをおこなう。これらは src/lib/libc/sys/Makefile.inc の SRC 変数に列挙されている。src/lib/libc/sys/lseek.c にシステムコールスタブにハンドルを追加する例がある
On the other side, some system call stubs are utterly void; they only do the system call. In this case, the source file for the system call stub is automatically generated. These are listed in the ASM variable in src/lib/libc/sys/Makefile.inc. An autogenerated stub looks like this:
一方、いくつかのシステムコールスタブには、たんにシステムコールを呼ぶだけで何もしないものがある。この場合、システムコールスタブのソースファイルは自動的に生成される。これらは src/lib/libc/sys/Makefile.inc に ASM 変数に列挙されている。たとえばこう。
#include "SYS.h" RSYSCALL(chdir)
Once generated, this file is src/lib/libc/chdir.S. The curious reader will look for the definition of the RSYSCALL macro, which is contained in src/lib/libc/arch/powerpc/SYS.h for PowerPC ports, for instance. The macro provides the few assembly lanugage instructions needed for the system call to set errno on error.
すると、src/lib/libc/chdir.S が生成される。好奇心旺盛なひとは、PowerPC ポートの src/lib/libc/arch/powerpc/SYS.h に RSYSCALL マクロが定義されていることに気付くだろう。このマクロは、システムコールがエラーになったときに errno を設定するための命令を提供する。
Before the clockctl implementation, adjtime(2), clock_settime(2), settimeofday(2), and ntp_adjtime(2) were implemented as the simple system call stubs. This has been changed in order to check for the existence and accessibility of /dev/clockctl.
先ほどの clockctl 実装 adjtime(2)、clock_settime(2)、settimeofday(2)、そして ntp_adjtime(2) は、簡単なシステムコールスタブとして実装されている。変更されたかどうか確認するには /dev/clockctl にアクセス出来るか確認すればよい{ ???????? }。
The code is nearly identical for the four system calls. It can be found for settimeofday(2) in src/lib/libc/sys/settimeofday.c. It performs roughly the following checks:
コードは 4 つのシステムコールとだいたい同じである。src/lib/libc/sys/settimeofday.c にある settimeofday(2) を見つけることができる。おおざっぱに以下のことをチェックする。
- Are we running with root UID? If we are, use the system call. Root has no reason to use clockctl.
- If we are not running with root UID, try to open /dev/clockctl and use the ioctl(2) to perform the settimeofday operation.
- 我々が root の UID でならばシステムコールを使う。root ならば clockctl を使う必要がない
- 我々が root の UID でなければ /dev/clockctl のオープンを試し、settimeofday の操作をするために ioctl(2) を使う
This turns each call to settimeofday(2) into several system calls: getuid(2), open(2), and ioctl(2). For the sake of performance, we have a keep-state feature, so that libc can remember if a process has already used clockctl. This is done using the __clockctl_fd variable. This variable is carried by libc but it behaves exaclty like a global variable for the process. Of course, each process has its own __clockctl_fd.
これは、getuid(2)、open(2)、そして ioctl(2) のいくつかのシステムコールで settimeofday(2) を呼ぶために返す。{???????????} パフォーマンス的な意味で keep-state の機能があるのだが、これにより、libc は clockctl がすでにプロセスから利用されているかを思い出すことができる{ ?????????? }。この処理は __clockctl_fd 変数を使えば完了する。__clockctl_fd 変数は、libc によって、プロセスのためのグローバル変数のように扱われる。もちろん、プロセスは独自の __clockctl_fd を持っている。
__clockctl_fd describes the state of the process regarding clockctl:
__clockctl_fd は clockctl に関するプロセスの状態として定義される:
- -2 means that the process never called settimeofday(2), adjtime(2), clock_settime(2), or ntp_adjtime(2). This is the value at initialization time.
- -1 means that the process should not use clockctl.
- Any other value is the file descriptor we got when opening /dev/clockctl.
- -2 はプロセスが settimeofday(2)、adjtime(2)、clock_settime(2)、ntp_adjtime(2) のいずれも呼ばなかったことを意味する。これは初期化時の値である
- -1 はプロセスが clockctl を使わなかったことを意味する
- それ以外の値は /dev/clockctl をオープンしたときのファイルディスクリプタである
On the first call to one of our four system call stubs, if UID is root, __clockctl_fd is immediatly set to -1. Otherwise, we attempt to open and use /dev/clockctl. Should this attempt fail, __clockctl_fd is set to -1. If it succeeds, then __clockctl_fd keeps the file descriptor returned by open(2). Future calls to the stub will use clockctl.
4 つのシステムコールスタブのうちの 1 つを初めて呼び出したとき、UID が root ならば __clockctl_fd は即座に -1 に設定される。/dev/clockctl をオープンしたり、利用するときも同様である。失敗したときも __clockctl_fd は -1 に設定される。成功したときは、open(2) の戻り値と同様にファイルディスクリプタとなる。将来的にはスタブは clockctl を使うようになるだろう。
When __clockctl_fd is -1, the real system call is always used.
__clockctl_fd が -1 だった場合、本当のシステムコールはすでに利用されている。
We end up with an implementation where the API for ntpd and other processes did not change. When the user process attempts to do a system call, we intercept it at the libc level and use either clockctl or the actual system call. This is nice, but the drawback is that we introduce some black magic in libc, which is not a nice solution. The good point is that since we did not change anything in the API, we can replace this black magic with anything else without disturbing user processes. For instance, if we ever introduce capabilities in NetBSD, we can revert to a void system call stub without ntpd being affected.
これで ntpd の API の実装は完了した。他のプロセスについては変更していない。ユーザープロセスがシステムコールを呼び出したとき、libc をぶんどり、clockctl か、またはシステムコールを利用させる。これはこれで良いのだが、libc の黒魔術でもあるのであまり良いともいえない。良い点は、我々は API をどれも変更していないことだ。ユーザープロセスに触れずに、libc の黒魔術だけで API を置き換えた。NetBSD だからこそ、ntpd を変更することなく、システムコールスタブを無効にできたのである。
_ [chroot][ntp][NetBSD][翻訳]chrooted ntpd in NetBSD - O'Reilly Media (2)
NetBSD で chroot な ntpd (2)
A word on the ioctl(2) system call and its use in clockctl: before talking about the changes to ntpd, it is worth explaining what the ioctl(2) system call does. On Unix systems, all objects are seen as files. This includes device files, terminals, and so on. Of course there are some object-specific operations that cannot be done through a file interface (read, write, lseek, etc.). These operations include, for instance, getting terminal characteristics when the file is the standard output, or ejecting the disk when the file is a a removable disk's device. Nearly everything that cannot be done through the standard file-related system calls is done using ioctl(2) calls.
clockctl 内で使用される ioctl(2) というシステムコールがある。ioctl(2) について知っておくとよいので、ntpd を変更する前に説明しておこう。Unix システムにおいて、すべてのオブジェクトはファイルである。それにはデバイスファイル、端末が含まれる。もちろんオブジェクトを扱う操作は、ファイルインターフェース無くしては出来ない( read、write、lseek など )。これらの操作には、ファイルが標準出力だったり、リムーバブルディスクを排出するときは、その端末から文字を取得することも含まれる。ファイルに関連する標準のシステムコールが無くてはほとんどのことは出来ないのだが、ioctl(2) を使えば出来る。
Here is ioctl(2)'s prototype:
ioctl(2) のプロトタイプはこう。
int ioctl(int d, unsigned long request, void *argp);
d is the file descriptor on which we operate, request is a value indicating which command we want to perform, and argp is an optional argument pointer. The structure of the argument itself depends on the request. Here is an example of ioctl use in a userland program, for getting the terminal width in columns:
d は操作するときに使用するファイルディスクリプタである。request はおこないたい処理で使う値である。argp はオプション引数のポインターである。引数の構造は request に依存する。以下にユーザーランドプログラムでの ioctl の例を示す。これは端末のカラム数を取得する。
/* col.c -- print the terminal width (端末の幅を印字する) */
#include <stdio.h>
#include <err.h>
#include <sys/ioctl.h>
int
main(void) {
struct winsize ws;
if (ioctl(1, TIOCGWINSZ, (void *)&ws) == 0)
printf("terminal width = %d\n", ws.ws_col);
else
err(1, "ioctl failed");
return 0;
}
In ioctl() first's argument, we have 1, standard output, which is attached to the controlling terminal. TIOCGWINSZ is a macro defined in <sys/ttycom.h> for getting window information on terminals. The third argument here is a pointer to a struct winsize where ioctl(TIOCGWINSZ) will write its data.
ioctl() の最初の引数は 1 である。これは制御する端末の標準出力を意味する。TIOCGWINSZ は <sys/ttycom.h> で定義されたマクロであり、端末のウィンドウについての情報を取得する。3 番目の引数は ioctl(TIOCGWINSZ) を実行して書き込まれる winsize 構造体へのポインターである。
Of course, TIOCGWINSZ will only work if the standard output is attached to a terminal. It's possible to check this:
もちろん TIOCGWINSZ は標準出力が端末になっているときにのみ動作する。以下のようにしてチェックする。
$ cc -o col col.c $ ./col terminal width = 80 $ ./col > toto col: ioctl failed: Inappropriate ioctl for device
For the clockctl device, we use four ioctl commands, one for each of our system calls. All are defined in <sys/clockctl.h>: CLOCKCTL_SETTIMEOFDAY, CLOCKCTL_ADJTIME, CLOCKCTL_CLOCK_SETTIME, and CLOCKCTL_NTP_ADJTIME. Each command uses a pointer to a structure holding the system call arguments for its arguments.
clockctl デバイスを使うためにシステムコールから成る 4 つの ioctl コマンドを使う。全て <sys/clockctl.h> で定義されていて、CLOCKCTL_SETTIMEOFDAY、CLOCKCTL_ADJTIME、CLOCKCTL_CLOCK_SETTIME、そして CLOCKCTL_NTP_ADJTIME がある。各コマンドは、該当するシステムコールの引数で使う構造体へのポインターを使う。
To keep things simple, we use exactly the same structures as kernel when passing arguments to system calls. They are defined in <sys/syscallargs.h>:
単純に保つために、カーネルがシステムコールの引数を扱うのと同じような構造体を使う。それらは <sys/syscallargs.h> で定義されている。
struct sys_settimeofday_args {
syscallarg(const struct timeval *) tv;
syscallarg(const struct timezone *) tzp;
};
struct sys_adjtime_args {
syscallarg(const struct timeval *) delta;
syscallarg(struct timeval *) olddelta;
};
struct sys_clock_settime_args {
syscallarg(clockid_t) clock_id;
syscallarg(const struct timespec *) tp;
};
syscallarg() is a macro that deals with machine-dependent alignment and endianness issues. It enables us to deal with machine-independent, system call argument structure declarations, whereas in fact these are really machine-dependent.
syscallarg() はマシン依存のアライメントを扱い、エンディアンを気にしないようにしている。マシン独立にすることによって、マシン依存の部分を気にせずシステムコールの引数として構造体を定義できるようになる。
There is a special case for ntp_adjtime, which needs to set the value returned to userland. Since ioctl(2) already uses it to indicate error conditions, it is not possible for an ioctl command to set ioctl's return value. We work around this by including the return value in the ioctl argument (this is from <sys/clockctl.h>:
ntp_adjtime はユーザーランドへ値を返すという特殊なものである。エラー状態を扱うために ioctl(2) が使われる{ あれ??? }のだが、ioctl コマンドは ioctl の戻り値を設定することは出来ない。これを回避するために ioctl 引数に戻り値を含めるようにした。<sys/clockctl.h> より:
struct clockctl_ntp_adjtime_args {
struct sys_ntp_adjtime_args uas;
register_t retval;
};
The sys_ntp_adjtime_args struct is defined in <sys/syscallargs.h>. The kernel uses it to store ntp_adjtime(2) arguments:
sys_ntp_adjtime_args 構造体は <sys/syscallargs.h> で定義されている。カーネルは store ntp_adjtime(2) 引数を格納するために使う。
struct sys_ntp_gettime_args {
syscallarg(struct ntptimeval *) ntvp;
};
Now that we have a precise idea of how the alternate entry points to the time-related kernel functions are made, let us move to kernel changes.
time-related kernel functions { ????????? } についてのエントリーポイントについて把握できたので、カーネルを変更しよう。
Kernel Changes: clockctl Device Driver Implementation ( カーネルの変更: clockctl デバイスドライバー実装 )
The clockctl device driver is a plain pseudodevice driver. There is some psuedodevice documentation explaining how to introduce such a driver into the NetBSD kernel. Since the kernel registration process is well described in the document, I will not cover it here. Let us focus on the driver structure itself. It can be found within the NetBSD sources in src/sys/dev/clockctl.c.
clockctl デバイスドライバーは疑似デバイスのドライバーである。疑似デバイスの文書には、NetBSD カーネルのデバイスドライバーの導入を説明したものがいくつかある。カーネルに慣れるにはこの文書はよいものなのだが、ここでは扱わない。clockctl ドライバーの構造体について注目しよう。NetBSD ソースの src/sys/dev/clockctl.c にある。
Each driver provides a set of functions, known as methods. The kernel calls the driver methods to execute operations such as open, read, write, ioctl, and so on. In NetBSD, the method names must be the name of actual operation prefixed with the driver name. For clockctl, we have clockctlopen(), clockctlread(), and so on.
各ドライバーは見慣れた関数群を提供する。カーネルは open、read、write、ioctl といったドライバー関数を呼び出す。NetBSD では、これらの関数はドライバーの接頭字がついた名前になる。clockctl では clockctlopen()、clockctlread() といったものだ。
When the user does an open(2) system call on the clockctl device file, the kernel will use the device major number to identify that the operation must be serviced by the clockctl driver. For character devices such as clockctl, this is done by reading the cdevsw array, which is defined in a machine-dependent file. (Unfortunately, driver major numbers are not unified on different NetBSD ports.) For the i386 port, the array is defined in src/sys/arch/i386/conf/majors.i386.
ユーザーが clockctl デバイスファイルにたいして open(2) システムコールを実行すると、clockctl ドライバーが操作するための識別子としてデバイスメジャー番号が使われる。clockctl のようなキャラクターデバイスは、cdevsw 配列(マシン依存のファイルで定義されている)の読み込みで完了する ( 残念ながらドライバーメジャー番号は NetBSD ポートで統一されていない )。i386 ポートでは、この配列は src/sys/arch/i386/conf/majors.i386 で定義されている。
Once the kernel knows which driver is to service the open request, it just calls the driver's open method. For read, write, ioctl, poll, and other operations, the process is the same. The actual code path is a bit complicated, because there are two abstraction layers before reaching the driver methods: the first makes any object appear to be a file to userland (this is done with struct file, defined in <sys/file.h>), and the second, known as the Virtual File System or VFS, enables the transparent use of different filesystem types (this is done using struct vnode, as defined in <sys/vnode.h>). An in-depth explanation of what happens exactly is out of the scope of this article, but it might pop up in an upcoming part of my series on IRIX binary compatibility on NetBSD.
カーネルは、ドライバーから open リクエストが来ると、ドライバーの open 関数を呼び出すだけである。read、write、ioctl、poll や他の操作についても同様である。ドライバーの関数へ辿りつくまでに 2 つの抽象化された階層があるので、コードの経路は割りと複雑である。最初の階層は、ユーザーランドにオブジェクトをファイルとして見せるためのものである( これには <sys/file.h> で定義された構造体を使う )。次の階層は、the Virtual File System や VFS として呼ばれ、異なるファイルシステム間を行き来できるようにする( これには <sys/vnode.h> で定義された vnode 構造体を使う )。これ以上深追いするのはこの文書の範囲を超えるのだが、NetBSD での IRIX バイナリ互換についての連載で取り扱うとする。
For clockctl, most methods are meaningless; only ioctl actually contains more than just return 0;. The ioctl method understands four commands, which we described in the section about libc.
clockctl のほとんどの関数は意味がない。ioctl だけがたんに 0 を返すだけではない処理をおこなう。ioctl 関数は先の章の libc で定義した 4 つの関数について知らない。この章では libc について説明する。
The job of the driver is really simple. A code snippet might say more than an explanation:
ドライバーの仕事はじつに簡単だ。以下のコード断片を見ていこう。
case CLOCKCTL_SETTIMEOFDAY: {
struct sys_settimeofday_args *args = (struct sys_settimeofday_args *)data;
error = settimeofday1(SCARG(args, tv), SCARG(args, tzp), p);
if (error)
return (error);
break;
}
SCARG() is another macro which deals with machine-dependent differences in the way system call arguments are structured. The clockctl driver just calls the function the settimeofday(2) system call normally would have called. The only difference is that clockctl does not check if the user is root, since the permissions are enforced at the filesystem level. To request this ioctl(2) command, you must have opened /dev/clockctl for writing.
SCARG() はシステムコールの引数の構造体について、マシン依存の差異を吸収するマクロである。clockctl ドライバーはただ settimeofday(2) システムコールを呼んでいるだけである。唯一の差異は{ なにとの差異だって???? }、clockctl はユーザーが root かどうかチェックしていないことだ。root パーミッションンはファイルシステムレベルで強制される。ioctl(2) コマンドの request は、オープン済みの /dev/clockctl に書き込めなくてはならない。
Userland Modification: ntpd (ユーザーランドの変更: ntpd)
As we said, we wanted to make as few modifications to ntpd as possible. This goal was achieved, since we only added command-line options to specify the UID/GID to run the process as, and the directory to chroot to after initialization, using the following two new flags: ntpd [-u user[:group]] [-i /path/to/jail].
前述したように、ntpd を少々変更しておきたい。最終的にはコマンドラインにオプションンを追加して、UID/GiD を指定してプロセスを実行できるようにし、初期化後に chroot するディレクトリを変更できるようにする。そのために 2 つのフラグを追加する: ntpd [-u user[:group]] [-i /path/to/jail]
There is very little to tell about these changes. There are probably some OSes with ACLified system calls where it was already possible for a non-root user to set the time. Therefore the changes are not really NetBSD-specific. This is why they have been sent to the NTP team in order to be included in the next NTP release. Propagating this change to the NTP team also ensures that the -i and -u flags will not be used for something else in the future. Having to face a conflict between new ntpd flags from the NTP distribution and the NetBSD locally-patched ntpd would be quite uncomfortable.
これらの変更についてはあまり語ることはない。おそらくいくつかの OS では ACLified な{ ACL された、ということ???? }システムコールで非 root ユーザーが時刻を設定できるようになっている。よって、この変更は本当は NetBSD には合わない。次の NTP のリリースに含めてくれるように NTP チームには投げておいた。NTP チームが -i と -u フラグを実装してくれるまでは当面フラグを使用できない。NTP 配布物との間に競合が発生してしまうし、NetBSD 用 ntpd パッチはじつに気持ち悪い。
Conclusions (最後に)
This work enables ntpd to be chrooted. The method we chose to do this is not perfect. One could argue (and in fact some have) that it is bad to introduce magic into libc. The best solution to chroot ntpd would indeed be to introduce capabilities, which are kind of ACLified system calls. Some Linux distributions now ship a ntpd daemon running under a non-root UID, and they do this using capabilities. This is a much better approach.
ここでは ntpd を chroot させてみた。この手段は完璧とはいえない。検討事項が 1 つある( 本当はもう少しあるけど )。それは ilbc の魔術に頼っていることだ。ntpd を chroot させる最良の手段は、ACL されたシステムコールを使用することだ。いくつかの Linux ディストリビューションでは ACL なシステムコールによって非 root UID のもとで ntpd デーモンを走らせている。これがもっとも最良なのだ。
However, capabilities alone are a huge project. TrustedBSD is a subproject of FreeBSD that is aimed toward the implementation of filesystem access lists, capabilities, and other security features. The project was started years ago and is not finished yet. On NetBSD, nobody is working on capabilities, and in fact, people are waiting for TrustedBSD to settle before importing some code. It could be a very long time before NetBSD would have capabilities available. In the meantime, clockctl appears to be a good solution for chrooting any time-related daemon.
しかし、これをやるには大規模なプロジェクトになる。TrustedBSD という FreeBSD のサブプロジェクトは、ファイルシステムアクセスリストと、いくつかのセキュリティ機能に狙いを絞ったものである。プロジェクトは数年前に開始されたが、まだ完了していない。NetBSD ではこれについて誰も作業していない。というか TrustedBSD の実装を盛り込むことを考えている。NetBSD でこの機能が使えるようになるのはだいぶ先になるだろう。それまでの間は時刻関連のデーモンを chroot させるのは clockctl でおこなうのが妥当である。
The advantages of clockctl are simplicity and the fact that we do not modify any existing APIs. The ntpd modifications are only about chrooting, not about the way time is controlled. The day we want to replace clockctl by capabilities, there is nothing to change in ntpd; it will work immediately.
clockctl のよいところは、簡単で、既存の API を変更しなくて済むというところだ。ntpd への変更は、chroot に限ったものだけだし、時刻制御の部分については手をつけていない。clockctl を置き換えたことにより ntpd を変更せずに済んだ。これはすぐに動作するはずだ。
Finally, it is worth mentioning orthogonal efforts to improve general daemon security. systrace was introduced by Matthieu Herrb and Niels Provos from the OpenBSD project, and was integrated into NetBSD by Christos Zoulas. It is now maintained by Niels Provos, who joined the NetBSD team in the meantime. systrace enables the system administrator to write a list of allowed system calls for a given daemon. The kernel will ensure the daemon does not do any other operations. That way, if the daemon gets compromised, it will not be able to execute things like system("/bin/sh"), even if it runs as root.
最後に、一般的にデーモンのセキュリティを向上させるために真面目に取り組むことは有意義である{ ???????????? }。systrace は OpenBSD プロジェクトの Matthieu Herrb と Niels Provos によって提供され、NetBSD には Christos Zoulas が取り込んだ。現在は Niels Provos がメンテナンスしており、その間は彼は NetBSD チームに所属している。systrace は、システム管理者がシステムコールを許可するデーモンのリストを作成するときに使うツールである。カーネルはデーモンに他の操作を許可しない。デーモンに不具合があったとしても、root で起動されたデーモンが system("/bin/sh") のような処理を実行させないようにできる。
On another orthogonal direction, Jason Thorpe has made changes to NetBSD-current in order to remove the need for an executable stack. On processors that support it (which is not the case for the old 80x86), the stack can therefore be set non-executable, thus making impossible the whole class of exploits that use stack buffer overflows. The non-executable stack is not a new idea; it can be found in various OSes, but it is extermely effective at reducing security holes, at least on machines with a processor modern enough to be able to set memory as non-executable.
他の取り組みとしては、Jason Thorpe が executable stack に必要なものを NetBSD-current から削除した。executable stack に対応したプロセッサでは( 古い 80x86 以外 )、スタックを non-executable に設定することができる。これはスタックバッファオーバーフローへの攻撃を可能にしてしまう。non-executable stack は新しいアイデアではない。様々な OS で実装されており、モダンなプロセッサを使っているマシンならばメモリを non-executable に設定することは、セキュリティホールを削減するのに極めて有効である。
Acknowledgements (謝辞)
Thanks to John Klos, Simon Burge, and Christos Zoulas for reviewing this article.
この文書をレビューしてくれた John Klos、Simon Burge、そして Christos Zoulas に感謝。
Emmanuel Dreyfus is a system and network administrator in Paris, France, and is currently a developer for NetBSD.
Emmanuel Dreyfus はフランスのパリでシステム管理とネットワーク管理をしている。現在は NetBSD 開発者である。
_ chrooted ntpd in NetBSD (訳注)
ところで ntpd -i じゃイカンのかしら( ntpd - NetBSD Manual Pages )。いつ入ったオプションか分からないけど( release note 嫁 )
2011-03-09 :-)
_ 午後
1330 実機
_ 夜
1700 自社へ
1800 課長と面談 || 部長に久しぶりに会ったので声かけたら「俺も混ぜろ」と言われて部長、課長、私の 3 者面談になった || 現状の惨状を報告するなど
1900 退勤
2100 飯
2200 RR7 Sunset Heights R での STARNOSE + ROLLING THUNDER 3 はスティックならなんとかなりそうだ
_ 永久Loop
最近ループしっぱなしである。どうも胸キュンすると思ったらテキトーなタイミングで音が入るメソッドが塊魂チックなのであるか。
2011-03-11 :-(
_ 午後
1300 研修 ＠有楽町電気ビル || あー ここ 7年前通ってたわー 7年前通ってたわー 20040204#p02
1445 地震 || ビルの 18F で講義受けてたのでものすごく揺れた。洒落になんない。死ぬかと思った
1500 まだ余震が続く。講義は終了する時刻なのだが地震により進まない
1515 講義は中止になった
1600 しばらく待機
_ 夜
1700 電車は停止
1720 いまだに余震が続くので諦めて徒歩での帰宅を試みることにしてみた。google map を見たらひたすら R412 → R246 を行けばよさそうだ。有楽町を出発
1750 国会議事堂前
1758 赤坂
1815 六本木
1852 渋谷
1925 池尻大橋
2009 駒沢大学
2034 用賀
2052 二子玉川
2130 帰宅 || 渋谷から長いわー ('A`)
2011-03-12 :-)
_ 午前
0430 起床。二度寝してた
0500 風呂。ちゃんと寝ようとしたけど緊急時に備えて NHK 総合をつけながら寝ておく
0600 緊急地震速報で起床した気がする
0700 とりあえず飯
0730 上司から連絡「いま帰宅」。こちらも把握してる状況だけ投げておいた
0800 寝る
_ 午後
1230 起床 || 部屋掃除
1300 おひる。うどん
1400 買い物。ヨーカ堂は品薄
1530 旧宅の植木を回収 && 鉢に植え替え
1600 台所の蛇口が緩んでいたので直してもらった
_ 夜
1700 コーヒー
1800 今日だけで Twitter 5,6 人ブロック or リムーブした。拡散希望とか非公式RTとか隠蔽厨とか不謹慎厨とか、さすがに見るに耐えない。
1900 こういうときは NHK のように淡々と放送してくれるのがありがたいというか普段から NHK ばかり見ておるので通常運転であった
2000 飯
_ 書見台を買った
はるか昔 山下達雄さんが「ほんたった」というのを紹介していた( [を] 本のページを開いたまま固定する話 )。机上に 1 つこういうのが欲しいと思いつつも、旧宅ではそもそも置くだけのスペースが無いのでもげもげしていたんだが、新居になって机を新調したのでスペースを確保できるようになったので買ってみた。こういう道具のことを書見台と言うのだね。
エキスパート Python プログラミングを立ててみたところ。だいぶ苦しい。
B001CR08MK
2011-03-13 :-)
_ [オレンジミント][ハーブ]ハーブ買ってきた
昨日ですが。
母の家庭菜園のために近所のホームセンターに寄ったら「手間いらず」などと書いてあったのでせっかくだから買ってみた。庭にはにわにわにわにわにわまだスペースがあるもんで。オレンジミントという
_ [amazon][EC2][NetBSD][翻訳]NetBSD Blog - NetBSD now runs under Amazon EC2
Amazon EC2 で NetBSD が動くようになった
March 13, 2011 posted by Jean-Yves Migeon
It is with great pleasure that we officially announce the release of the first NetBSD Amazon Images for the Amazon Elastic Compute Cloud (better known as Amazon EC2) for all currently available regions: US East (Northern Virginia), US West (Northern California), EU (Ireland), Asia Pacific (Singapore), and Asia Pacific (Tokyo).
Amazon Elastic Compute Cloud ( Amazon EC2 としてよく知られている ) のすべてのリージョンで使える NetBSD Amazon Images の最初のリリースを公式に発表できることを嬉しく思う。リージョンとは、東アメリカ (北バージニア)、西アメリカ (北カリフォルニア)、EU (アイルランド)、アジア太平洋 (シンガポール)、アジア太平洋(東京)である。
For those not familiar with the cloud world, Amazon EC2 is an infrastructure provider. It allows you to rent virtual machines for your own use utilizing the Amazon Web Services.
Amazon EC2 は、クラウドというより、インフラストラクチャプロバイダである。Amazon ウェブサービスを自分で使える仮想マシンを提供してくれる。
Lately, Amazon has opened up its architecture to permit running third party operating systems within the Amazon cloud. Given that Amazon uses Xen as the virtualization technology of the cloud, and that NetBSD has had strong Xen support since the early days, it was a natural step to make NetBSD run under EC2.
最近では Amazon EC2 はサードパーティ製のオペレーティングシステムを Amazon クラウドで使えるように設計してくれた。クラウドの仮想化技術として Amazon は Xen を使用している。そして NetBSD は以前から Xen にちゃんと対応している。EC2 のもとで NetBSD を使うことは自然のことなのだ。
For more information please see the NetBSD EC2 wiki page:
詳細は NetBSD EC2 wiki ページを参照
http://wiki.netbsd.org/amazon_ec2/
For running NetBSD AMIs, all you need is an AWS account, a browser and an ssh client.
NetBSD AMI を使うには AWS アカウントと、ブラウザと、ssh クライアントが必要である。
To create and manipulate your own AMIs, or to manipulate storage, the following packages are available in pkgsrc:
独自の AMI を作成したり、操作したり、ストレージを操作するには以下の pkgsrc を使うとよい。
- EC2 AMI tools (misc/ec2-ami-tools)
- EC2 API tools (misc/ec2-api-tools)
I would like to thank:
感謝
- Manuel Bouyer and Christoph Egger from NetBSD for their work on Xen support for NetBSD.
- Colin Percival from FreeBSD for providing guidance and help running NetBSD inside EC2.
- the entire NetBSD community for their support.
- Manuel Bouyer と Christoph Egger は NetBSD での Xen 対応をしてくれた
- Colin Percival は NetBSD を EC2 で使うための手引きとヘルプを書いてくれた
- すべての NetBSD コミュニティ
Without them this project would not have been possible.
このプロジェクトは彼らのおかげである。
2011-03-14 :-(
_ リッジレーサーズ2
PSP リッジレーサーズ2 の MAX ツアーを制覇してなかったのでやってみたんだが、こんなのクリアできるかああああああ
_ 秘密の画像と動画
( エキスパート Python p.96 )
#!/usr/bin/python
# -*- coding:utf8 -*-
class folder(list):
def __init__(self, name):
super(folder, self).__init__()
self.name = name
def dir(self):
print("I am the %s folder: " % self.name)
for element in self:
print(element)
the = folder('secret')
print the
the.append('pics')
the.append('videos')
print the.dir()
つまりエロｒｙ
_ [NetBSD][翻訳]NetBSD Blog - NetBSD at the 17th LinuxTag in Berlin
March 14, 2011 posted by Marc Balmer
The 17th LinuxTag takes place from May 11th - 14th, 2011 in Berlin.
2011 年 5 月 11 日 ～ 14 日 ベルリンで第 17 回 LinuxTag が開催される。
In the last years there were 10,000 - 11,500 visitors from all over the world in the Berlin Exhibition Grounds. There are a lot of exhibitioner all around open source software.
去年は Berlin Exhibition Grounds に世界中から 1万～1万5千人が参加した。あらゆるオープンソースソフトウェアからたくさんの出展者がつどう。
The slogan oft the LinuxTag convention is "Where .com meets .org". Not only established and ambitious free projects take part, but also companies, which support free software.
LinuxTag 会議のスローガンは「.com と .org の出会い」。すべての出展者が必ずしもフリープロジェクトに貢献していたり、積極的であるわけではないし、フリーソフトウェアをサポートしている企業もいる。
Every day the visitors can choose between different workshops, keynotes and lectures.
来訪者は毎日開催されるワークショップやキーノートやレクチャーから選択できる。
More about the programm you can read on www.linuxtag.org.
プログラムの詳細は www.linuxtag.org 参照 { LinuxTag 2011 }
NetBSD is presented together with other BSD's.
NetBSD は他の BSD と同様に参加している。
If you staying in Berlin during this time, then visit the LinuxTag!
この期間にベルリンに滞在するならば、LinuxTag に参加しよう!
Do you want to get some more informations or help on the NetBSD-booth? Please, contact Thomas Kaepernick (mast_1 (at) gmx.net).
NetBSD ブースの詳細が知りたいかい? Thomas Kaepernick (mast_1 (at) gmx.net) に連絡してくれ。
2011-03-15 :-(
_ 午前
0500 地震 && 起床
0610 IDカードを忘れたことに気付いたので振り出しに戻る
0640 南武線 武蔵溝ノ口到着
0740 4 本くらい電車を待ったが混雑のため結局乗れず
0800 @huhehe からのツッコミによりバスの存在を思いだす || バス通勤
1000 川崎到着
1020 出勤
2011-03-16 :-(
_ [NetBSD][翻訳][rump]NetBSD Blog - Rump: Distributed Kernel Services For NetBSD
Rump: NetBSD のカーネル配布サービス
March 15, 2011 posted by Antti Kantee
Rump is a componentization of the NetBSD kernel. It lends itself to multiple uses, such as running kernel code as services in userspace and for example makes the high-quality NetBSD kernel code base available for use in multiserver microkernel operating systems.
Rump は NetBSD カーネルの構成要素である。Rump にはいくつかの使い方がある。ユーザー空間のサービスとしてカーネルコードを走らせたり、たとえば、マイクロカーネルのオペレーティングシステムで複数のサーバーとして利用するときに高品質な NetBSD カーネルコードを提供したりする。
Running unmodified NetBSD kernel code in standalone userspace applications has been possible for years. Recently, it also became possible to use unmodified userland binaries as remote clients for these lightweight and modular kernel server instances. Things work straight out of the default NetBSD installation. For example, it is possible to run an unmodified web browser against a rump TCP/IP server and restart the TCP/IP server with minimal impact to the browser. Furthermore, it is possible to run a dedicated TCP/IP server for every networking application on the system. The combined flexibility of using proven kernel drivers in lightweight virtual servers is completely unique to NetBSD.
素の NetBSD カーネルコードをスタンドアローンのユーザー空間アプリケーションとして走らせることができるようになったのはここ数年である。最近は軽量化されたリモートのクライアントとして特にバイナリを修正せずに使えるし、モジュール化カーネルをサーバーインスタンスとすることもできる。これは NetBSD をインストールしたときから使える。例えば、素のウェブブラウザで rump TCP/IP サーバーを使えるし、TCP/IP サーバーを再起動するだけでよいのでウェブブラウザへの影響は最小限になる。さらに、システム上のすべてのネットワークアプリケーション向けの TCP/IP サーバーとすることもできる。軽量仮想サーバーで承認済みカーネルドライバー { ?????? }を使う、という複合された柔軟性は、NetBSD ならではのものだ。
I have written two documents. One is a technical document explaining how the rump client/server architecture works and the other one is a tutorial targetted at users interested in testing how things work in practise. They can be read independent of each other. However, as things work slightly differently than in the classic microkernel / userspace OS / distributed OS / virtualization world, it is recommended to at least skim over the first two introductory sections of the tutorial to properly orient oneself for the technical article.
2 つの文書を書いた。1 つは rump クライアント/サーバーのアーキテクチャの仕組みを説明した技術文書である。もう 1 つはテストをしたいユーザー向けに操作方法を書いたチュートリアルだ。各々独立した文書になっている。しかしクラシックマイクロカーネル、ユーザー空間 OS 、分散 OS、仮想世界と大差ないし、チュートリアルの最初の 2 章を読むだけで技術文書を読めるようになる。
- article ( 技術文書 )
- tutorial ( チュートリアル )
The implementation is production quality, so it is immediately possible to use and even build products on the features described.
実装は製品レベルの品質になっているのですぐに使えるし、機能の説明としてビルドすることもできる { 評価に使うということ????? }
Enjoy!
ゆっくりしていってね!!!
2011-03-17 :-(
_ 夜
1800 川崎発 && 多摩川徒歩
1830 ガス橋
1930 等々力
2000 帰宅 || 夕方以降の多摩川は西から東への風なので( なぜかそういうパターン )つまり向かい風であり体力を著しく削られた。多摩川なんて歩くものではない
_ 魔法少女まどか☆マギカ #10
あわせて読みたい: 紫色のクオリア
などというように過去にあった事柄に当てはめ、パターン化してしまい、分かったつもりになってしまう。
あとどうでもいいけど さやか(witch) はサルーインだと思いながら見ていた。
404867904X
2011-03-18 :-(
_ おしえて! えらいひと
東電のエライ人くらいになるとウェルナー・ロックスミス(プラネテス)のひとのように「爆発した原発の残したデータの内容には満足しています。次は失敗しません。御期待下さい」くらいの神経じゃないとやってられんのだろうな。
2011-03-21 :-)
_ [NetBSD][ruby][pkgsrc][gmake]NetBSD/i386 で ruby-1.8.7-p334 で make が失敗した
% make -dA
:
*** Failed target: Makefile
*** Failed command: { echo "all:; -@rm -f conftest.mk"; echo "conftest.mk: .force; @echo AUTO_REMAKE"; echo ".force:"; } > conftest.mk || exit ; make -f conftest.mk | grep '^AUTO_REMAKE$' >/dev/null 2>&1 || { echo "Makefile updated, restart."; exit 1; }
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/lang/ruby18-base/work/ruby-1.8.7-p334
Global:.ERROR_TARGET = Makefile
Applying :@ to ""
Modifier pattern: "v"
Modifier pattern: "$v='${$v}'
"
Result of :@ is ""
Makefile のここの部分
$(MKFILES): config.status $(srcdir)/common.mk
MAKE=$(MAKE) $(SHELL) ./config.status
@{ \
echo "all:; -@rm -f conftest.mk"; \
echo "conftest.mk: .force; @echo AUTO_REMAKE"; \
echo ".force:"; \
} > conftest.mk || exit 1; \
$(MAKE) -f conftest.mk | grep '^AUTO_REMAKE$$' >/dev/null 2>&1 || \
{ echo "Makefile updated, restart."; exit 1; }
Failed command を分割したらここが失敗してた。
make -f conftest.mk | grep '^AUTO_REMAKE$' >/dev/null 2>&1
conftest.mk の中身はこう
all:; -@rm -f conftest.mk conftest.mk: .force; @echo AUTO_REMAKE .force:
ubuntu で make する
% make -n -f conftest.mk AUTO_REMAKE rm -f conftest.mk
NetBSD で make する
% make -n -f conftest.mk rm -f conftest.mk
あー
gmake 使えっていう
文書 によると Chapter 22. Frequently Asked Questions - 22.2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM? USE_TOOLS に += gmake しろと書いてあるので Makefile に追加
USE_TOOLS+= pax yacc gmake
これでおｋ
send-pr してみたら「再現しないんだけど? NetBSD アップデートしろ」と返答がきたので current にしようとしたら起動しなくなった('A`) ので 5.1 にしてみた。再現しない。すんませんでした。
2011-03-25 :-(
_ 夜
1800 自社 || 書類提出
2000 飯。ラーメン。かんたん煮豚 の煮汁が大量に余ったので勿体ないのでラーメンにしてみた。ふむ
2300 ふと PS3 を起動してみたら何人かフレンドが居たので RR7 やってた
0300 寝る
_ [pkgsrc][NetBSD]pkgsrc
毎回インストールするこれ
#!/bin/sh
pkgsrcdir=/usr/pkgsrc
pkgs="\
/misc/gnuls \
shells/zsh \
www/w3m \
net/wget \
editors/vim \
lang/ruby18-base \
lang/python \
devel/mercurial \
misc/lv \
lang/perl5 \
misc/rubygems \
net/rsync \
converters/nkf \
pkgtools/pkg_chk \
devel/bmake \
pkgtools/url2pkg \
pkgtools/pkglint \
pkgtools/port2pkg \
security/sudo \
misc/screen \
net/samba35 \
net/djbdns \
"
for p in $pkgs; do
cd ${pkgsrcdir}/${p} && make install clean clean-depends
done
2011-03-26 :-)
_ [リッジレーサー7]リッジレーサー7 ARC 2010 弥生GP
- knhtymh 167
- REDOGRE 130
- ANSΩkeyaki 124
- すたきち 113
- Locus 85
- agumon11 84
- CONTI4X 71
- SOLARE 65
- ANSΩ三嶋出雲 52
- かず 47
- megu.Girls 36
- ANSΩmiwarin 29
- ANSΩbrother 26
- ANSΩ限無 1
相変わらず真の敵が回線だったのでルームオーナーを CONTI4X さんにやってもらったり三嶋さんにやってもらうなどし結局三嶋さんに運営してもらった。私は点数集計に専念できたので実に助かった。ありがとうゴマス (・ω・)ノ
けやきんはなんだかんだでやはり速いじゃなイカ
その後 Locus さん 6666 勝阻止レース。1 時間くらいかしら。お疲れ様でした。
- 走行距離 97656 km
- RSGP 進行度 100.0 %
- 名声 26366 FP
- オンラインバトル勝利数 1179/4240
_ [リッジレーサー7]リッジレーサー7 ARC2010 終了
1 年間続けてきた ARC2010 が終了した。参加してくれた皆様ありがとうござしました。
総合結果 上位 10 人
- ANSΩB2マンタレイ 1343
- CONTI4X 1045
- ANSΩ三嶋出雲 1018
- ANSΩmiwarin 976
- Locus 754
- rosso 737
- agumon11 648
- SOLARE 533
- ANSΩkeyaki 517
- emotion21 507
B2 さんブッチギリ。私なんてすべて参加してるから総合得点が多いだけであるよ ('A`)
もともと リッジレーサー7 で
過疎化が進んでいるRR7を盛り上げていきましょう。
と、けやきんが言っているように、リッジレーサー7 の灯火を絶やさないために、また、途中から けやきんが事情により 1 年間近く留守にするので、それまでリッジレーサー7 を続け、けやきんが復帰したときにリッジレーサー7 で迎えるために始めたものである。私がいろいろなひとと走りたかったという理由もある。動画でしか見たことがないあの人とか 2ch でレジェンド扱いされているあの人とか。
GT5 が発売されるとリッジレーサー7 のオンラインバトル参加者が激減しいよいよ風前の灯火になるかと思ったものだが、なんだかんだで PSN フレンドのひとたちは時折リッジレーサー7 をプレイしているようだった。みんな大好きリッジレーサー。
あと 1 年くらい続けてみようか。
2011-03-27 :-)
2011-03-30 :-(
_ 夜
1900 昼寝
2000 IRC を眺めていたら ニコ生シノドス・大震災スペシャル「ニセ情報に気をつけろ！ 生き残るための情報戦略」 - ニコニコ生放送 八代嘉美さんが出演するということで見てた。
2011-03-31 :-(
_ 午後
1400 実機
_ [NetBSD][翻訳][The tier system][port]NetBSD Blog - Port tier system introduced
ポート層システムの紹介
March 30, 2011 posted by Antti Kantee
The NetBSD core team has announced a tier system for the hardware architectures supported by NetBSD. The tier system classifies ports into three tiers. Summarizing, the tiers consist of ports that NetBSD will support, ports that NetBSD does its best to support, and ports which may be desupported soon. The purpose of this classification is to clarify the development roles between old and new architectures. By making modern architectures an official development priority, the tier system ensures that NetBSD will continue to be the top choice for a fast, secure and portable free OS on the hardware of today and tomorrow.
NetBSD コアチームは、NetBSD が対応しているハードウェアアーキテクチャのティアシステム{ 階層システムと呼ぶ?????} を アナウンスした 。ティアシステムは、3 つの層に分類されたポート である。つまり、NetBSD が対応する予定のポート、NetBSD の対応が完璧であるポート、間もなく対応から除外されるポートのことである。この分類の目的は、古いアーキテクチャと、新しいアーキテクチャを開発する立場を明確にすることである。モダンなアーキテクチャは公式な優先度となる。ティアシステムは、今後も NetBSD がハードウェア上で高速でセキュアでポータブルなフリー OS であることが最も優先度が高くあり続ける。
