From owner-svn-doc-all@FreeBSD.ORG Tue Nov 19 10:07:16 2013 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E046D567; Tue, 19 Nov 2013 10:07:16 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CED462232; Tue, 19 Nov 2013 10:07:16 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id rAJA7GfT048376; Tue, 19 Nov 2013 10:07:16 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id rAJA7G1f048373; Tue, 19 Nov 2013 10:07:16 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201311191007.rAJA7G1f048373@svn.freebsd.org> From: Ryusuke SUZUKI Date: Tue, 19 Nov 2013 10:07:16 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43205 - in head/ja_JP.eucJP/books/handbook: basics security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 19 Nov 2013 13:06:35 +0000 X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 10:07:17 -0000 Author: ryusuke Date: Tue Nov 19 10:07:16 2013 New Revision: 43205 URL: http://svnweb.freebsd.org/changeset/doc/43205 Log: - Merge the following from the English version: r17055 -> r17170 head/ja_JP.eucJP/books/handbook/basics/chapter.xml - Move "File System Access Control Lists" from Unix Basics chapter to Security chapter. head/ja_JP.eucJP/books/handbook/security/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/basics/chapter.xml head/ja_JP.eucJP/books/handbook/security/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/basics/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/basics/chapter.xml Tue Nov 19 08:50:46 2013 (r43204) +++ head/ja_JP.eucJP/books/handbook/basics/chapter.xml Tue Nov 19 10:07:16 2013 (r43205) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: 1.97 + Original revision: r17170 $FreeBSD$ --> @@ -38,10 +38,6 @@ Unix のファイルの許可属性の仕組み - ファイルシステムの ACL (アクセス制御リスト) - とは何か、またその使用法 - - プロセス、デーモンとシグナルとはなにか @@ -217,111 +213,6 @@ &man.chmod.1; マニュアルページを参照してください。 - - ファイルシステムアクセス制御リスト - - TomRhodes寄稿: - - - - - - - ACL - - - スナップショットのようなファイルシステムの拡張と連携して、 - FreeBSD 5.0 以降ではファイルシステムアクセス制御リスト - (ACLs) によるセキュリティを提供しています。 - - アクセス制御リストは、標準的な UNIX のパーミッションモデルを、 - 非常に互換性の高い (POSIX.1e) やり方で拡張しています。 - この機能は、管理者がより洗練されたセキュリティモデルを利用し、 - その恩恵を受けられるようにします。 - - UFS ファイルシステム用の - ACL サポートを有効にするには、 - 次のオプションをカーネルに組み込まなければなりません。 - - options UFS_ACL - - もしこのオプションが組み込まれていなければ、ACLs - に対応したファイルシステムをマウントしようとすると、 - 警告が表示されます。このオプションは GENERIC - カーネルに含まれています。ACLs - は、ファイルシステムの拡張属性が有効になっていることに依存しています。 - 拡張属性は、次世代 UNIX ファイルシステムである UFS2 - でネイティブ対応されています。 - - UFS1 に拡張属性を付すように設定するのは、 - UFS2 よりも高いレベルの管理オーバヘッドが必要になります。 - また、UFS2 - における拡張属性のパフォーマンスも大きく上がっています。 - その結果、アクセス制御リストを利用する上では、一般的には - UFS1 よりも UFS2 - の方がおすすめです。 - - ACLs は、マウント時の管理フラグ - で有効にされます。これは /etc/fstab に記述できます。 - マウント時のフラグは、&man.tunefs.8; - を使って、ファイルシステムヘッダのスーパブロックにある - ACLs フラグを変更するという方法で、 - 常に自動で設定されるようになります。一般的には、 - 下記の理由からスーパブロックフラグを使う方がよいでしょう。 - - - - マウント時に指定した ACLs フラグは再マウント - (&man.mount.8; ) 時に変更できません。完全に - &man.umount.8; した上で、新たに &man.mount.8; - するしかありません。これは、起動後にルートファイルシステムで - ACLs を有効にできないことを意味します。 - また、ファイルシステムを利用し始めた後では、 - その配列を変えられないことも意味しています。 - - - - スーパブロックフラグを設定すると、fstab - に記述されていなかったり、デバイスの順番が変わってしまっても、常に - ACLs が有効な状態でマウントされます。 - こうすることで、ファイルシステムを ACLs - を有効にしないままマウントしてしまい、ACLs - が正しくないかたちで強制され、 - セキュリティ問題につながることを防ぎます。 - - - - ACLs の動作を変更して、まったく新たに - &man.mount.8; を行わなくてもフラグを有効にできるようにすることも可能でしょう。 - しかし、我々は、うっかり ACLs - を有効にしないでマウントしてしまうのを防ぐようにした方が望ましいと考えました。 - ACLs を有効にし、その後無効にしてから、 - 拡張属性を取り消さないでまた有効にしてしまうと、 - 鬱陶しい状態に自分で入り込んでしまえるからです。 - 一般的には、一度ファイルシステムで ACLs - を有効にしたら、無効にすべきではありません。そうしてしまうと、 - ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 - ACLs を再度有効にすると、 - それまでパーミッションが変更されてきたファイルに古い - ACLs を割り当ててしまい、 - 予想しない動作につながることも考えられます。 - - ACLs を有効にしたファイルシステムは、 - パーミッション設定の表示に + (プラス) - 記号がつきます。例えば、次のようになります。 - - drwx------ 2 robert robert 512 Dec 27 11:54 private -drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 -drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 -drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 -drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html - - ここでは、ディレクトリ directory1, - directory2 および directory3 - のすべてで ACLs が働いています。 - ディレクトリ public_html は対象外です。 - - ディレクトリ構造 ディレクトリの階層構造 Modified: head/ja_JP.eucJP/books/handbook/security/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/security/chapter.xml Tue Nov 19 08:50:46 2013 (r43204) +++ head/ja_JP.eucJP/books/handbook/security/chapter.xml Tue Nov 19 10:07:16 2013 (r43205) @@ -80,6 +80,11 @@ modules using the TrustedBSD MAC Framework. --> + + + ファイルシステムの ACL (アクセス制御リスト) + とは何か、またその使用法 + この章を読む前に、次のことが必要になります。 @@ -4019,4 +4024,109 @@ user@unfirewalled.myserver.com's passwor --> + + + ファイルシステムアクセス制御リスト + + TomRhodes寄稿: + + + + + + + ACL + + + スナップショットのようなファイルシステムの拡張と連携して、 + FreeBSD 5.0 以降ではファイルシステムアクセス制御リスト + (ACLs) によるセキュリティを提供しています。 + + アクセス制御リストは、標準的な UNIX のパーミッションモデルを、 + 非常に互換性の高い (POSIX.1e) やり方で拡張しています。 + この機能は、管理者がより洗練されたセキュリティモデルを利用し、 + その恩恵を受けられるようにします。 + + UFS ファイルシステム用の + ACL サポートを有効にするには、 + 次のオプションをカーネルに組み込まなければなりません。 + + options UFS_ACL + + もしこのオプションが組み込まれていなければ、ACLs + に対応したファイルシステムをマウントしようとすると、 + 警告が表示されます。このオプションは GENERIC + カーネルに含まれています。ACLs + は、ファイルシステムの拡張属性が有効になっていることに依存しています。 + 拡張属性は、次世代 UNIX ファイルシステムである UFS2 + でネイティブ対応されています。 + + UFS1 に拡張属性を付すように設定するのは、 + UFS2 よりも高いレベルの管理オーバヘッドが必要になります。 + また、UFS2 + における拡張属性のパフォーマンスも大きく上がっています。 + その結果、アクセス制御リストを利用する上では、一般的には + UFS1 よりも UFS2 + の方がおすすめです。 + + ACLs は、マウント時の管理フラグ + で有効にされます。これは /etc/fstab に記述できます。 + マウント時のフラグは、&man.tunefs.8; + を使って、ファイルシステムヘッダのスーパブロックにある + ACLs フラグを変更するという方法で、 + 常に自動で設定されるようになります。一般的には、 + 下記の理由からスーパブロックフラグを使う方がよいでしょう。 + + + + マウント時に指定した ACLs フラグは再マウント + (&man.mount.8; ) 時に変更できません。完全に + &man.umount.8; した上で、新たに &man.mount.8; + するしかありません。これは、起動後にルートファイルシステムで + ACLs を有効にできないことを意味します。 + また、ファイルシステムを利用し始めた後では、 + その配列を変えられないことも意味しています。 + + + + スーパブロックフラグを設定すると、fstab + に記述されていなかったり、デバイスの順番が変わってしまっても、常に + ACLs が有効な状態でマウントされます。 + こうすることで、ファイルシステムを ACLs + を有効にしないままマウントしてしまい、ACLs + が正しくないかたちで強制され、 + セキュリティ問題につながることを防ぎます。 + + + + ACLs の動作を変更して、まったく新たに + &man.mount.8; を行わなくてもフラグを有効にできるようにすることも可能でしょう。 + しかし、我々は、うっかり ACLs + を有効にしないでマウントしてしまうのを防ぐようにした方が望ましいと考えました。 + ACLs を有効にし、その後無効にしてから、 + 拡張属性を取り消さないでまた有効にしてしまうと、 + 鬱陶しい状態に自分で入り込んでしまえるからです。 + 一般的には、一度ファイルシステムで ACLs + を有効にしたら、無効にすべきではありません。そうしてしまうと、 + ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 + ACLs を再度有効にすると、 + それまでパーミッションが変更されてきたファイルに古い + ACLs を割り当ててしまい、 + 予想しない動作につながることも考えられます。 + + ACLs を有効にしたファイルシステムは、 + パーミッション設定の表示に + (プラス) + 記号がつきます。例えば、次のようになります。 + + drwx------ 2 robert robert 512 Dec 27 11:54 private +drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 +drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 +drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 +drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html + + ここでは、ディレクトリ directory1, + directory2 および directory3 + のすべてで ACLs が働いています。 + ディレクトリ public_html は対象外です。 +