From owner-p4-projects@FreeBSD.ORG Tue Nov 11 17:23:41 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id AB04A16A4D0; Tue, 11 Nov 2003 17:23:41 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 849C316A4CE for ; Tue, 11 Nov 2003 17:23:41 -0800 (PST) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8BFC43FBF for ; Tue, 11 Nov 2003 17:23:40 -0800 (PST) (envelope-from kensmith@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.9/8.12.9) with ESMTP id hAC1NeXJ023266 for ; Tue, 11 Nov 2003 17:23:40 -0800 (PST) (envelope-from kensmith@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.12.9/8.12.9/Submit) id hAC1NelA023263 for perforce@freebsd.org; Tue, 11 Nov 2003 17:23:40 -0800 (PST) (envelope-from kensmith@freebsd.org) Date: Tue, 11 Nov 2003 17:23:40 -0800 (PST) Message-Id: <200311120123.hAC1NelA023263@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to kensmith@freebsd.org using -f From: Ken Smith To: Perforce Change Reviews Subject: PERFORCE change 42068 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 01:23:42 -0000 http://perforce.freebsd.org/chv.cgi?CH=42068 Change 42068 by kensmith@kensmith_oliver.cse.buffalo.edu on 2003/11/11 17:22:58 - Beginning to expand on vnode operation descriptions. Affected files ... .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/arch-handbook/secarch/chapter.sgml#7 edit Differences ... ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/arch-handbook/secarch/chapter.sgml#7 (text+ko) ==== @@ -988,7 +988,7 @@ - create() + VOP_CREATE() Create a new file system object; parent directory, name, and initial attributes are specified. @@ -998,7 +998,7 @@ - whiteout() + VOP_WHITEOUT() Create or remove whiteout for a directory entry, permitting files to be "deleted" and "undeleted" on @@ -1011,18 +1011,19 @@ - mknod() + VOP_MKNOD() Create a special device node in the file system; name, initial protections, and device information are - specified. + specified. Note that block devices can be created + but are not used by FreeBSD. - open() + VOP_OPEN() Indicate and request an open on a file system object to the file system, permitting the file system @@ -1037,16 +1038,18 @@ - close() + VOP_CLOSE() - + Called when a file is closed. Actions are file system + dependent but may include things like updating time + stamps or scheduling final write operations. - access() + VOP_ACCESS() Request an authorization check to determine whether a given subject credential and thread may perform a @@ -1061,7 +1064,7 @@ - getattr() + VOP_GETATTR() Retrieve an attribute structure for the file system object; authorizing credential and thread are @@ -1072,7 +1075,7 @@ - setattr() + VOP_SETATTR() Set components of an attribute structure for the file system object; optionally completed attributes, @@ -1084,7 +1087,7 @@ - read() + VOP_READ() Read from the file system object; read arguments, operation flags, and authorizing credential are @@ -1095,7 +1098,7 @@ - write() + VOP_WRITE() Write to the file system object; write arguments, operation flags, and authorizing credential are @@ -1106,18 +1109,23 @@ - ioctl() + VOP_IOCTL() - + Perform an operation other than open, close, read, + write on a file object. Typically used on devices + to set device modes or perform device-specific operations + like ejecting a tape from a tape drive. - poll() + VOP_POLL() - + Poll a file object to see if requested I/O operation is + possible. Used to help support &man.select.2; among other + things. @@ -1133,9 +1141,15 @@ - revoke() + VOP_REVOKE() - + Revoke access to a file object. Used to support forced + unmounting of filesystems without needing to + blindly kill off all processes with files + open in that filesystem. Typically file operations that + would modify or read from the object will fail after the + object is revoked but operations like &man.close.2; will + be allowed to succeed. @@ -1363,20 +1377,28 @@ File System Object Protections - -VFS generally relies on file systems to implement per-filesystem -protections based on their own design and implementation requirements. -access() entry point permits file system independent code to query -file systems concerning access to an object, and will be used during -open and new access operations, such as file execution.; file systems -may also implement protections in other entry points. -However, the native UNIX protection model includes object ownership, -simple and extended DAC access controls, file flags providing additional -protection semantics for the file owner and system operator. - + + VFS generally relies on file systems to implement + protections based on their own design + and implementation requirements. For example the + file system support for FAT file systems needs to + improvise file ownership because there + is no way to store file ownership information in the + FAT file system data structures. The VOP_ACCESS(9) entry + point permits file system independent code to query + file systems concerning access to an object, and will + be used during &man.open.2; as well as other operations, + such as file execution. File systems may also implement + protections in other entry points, for example + VOP_LOOKUP(9). + However, the native UNIX protection model includes object + ownership, simple and extended DAC access controls, and file + flags providing additional protection semantics for the file + owner and system operator. + + + UFS Inode Properties - - UFS Inode Properties In the UNIX File System (UFS), protections are generally at the granularity of the individual file system object, represented by an