From owner-freebsd-arch Sun Apr 30 4:23:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B699337BC6B for ; Sun, 30 Apr 2000 04:23:29 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA05348 for ; Sun, 30 Apr 2000 13:23:24 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA11273 for freebsd-arch@freebsd.org; Sun, 30 Apr 2000 13:23:23 +0200 (CEST) Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id B04DE37B92A; Sun, 30 Apr 2000 04:22:29 -0700 (PDT) (envelope-from darius@guppy.dons.net.au) Received: from guppy.dons.net.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.9.3/8.9.1) with ESMTP id UAA01549; Sun, 30 Apr 2000 20:52:25 +0930 (CST) (envelope-from darius@guppy.dons.net.au) Received: (from darius@localhost) by guppy.dons.net.au (8.9.3/8.9.3) id UAA00577; Sun, 30 Apr 2000 20:52:20 +0930 (CST) (envelope-from darius) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200004282005.NAA27418@usr08.primenet.com> Date: Sun, 30 Apr 2000 20:52:19 +0930 (CST) From: "Daniel O'Connor" To: Terry Lambert Subject: Re: How about building modules along with the kernel? Cc: freebsd-arch@freebsd.org, (Daniel O'Connor) , (Richard Wackerbarth) , (Mike Smith) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28-Apr-00 Terry Lambert wrote: > I think the issue is being raised in the context of dual boot > machines; ifit weren't, then "JFS, E2FS, KFS, etc." would have > no relevence, as you say. > I think you are missing the context here. I wasn't under that impression. I think having *our* boot loader grok *other* OS's is a little silly. They have their own boot loaders :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Apr 30 14:41:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 15A0737BA5F for ; Sun, 30 Apr 2000 14:41:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA08669 for ; Sun, 30 Apr 2000 23:41:22 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA11972 for freebsd-arch@freebsd.org; Sun, 30 Apr 2000 23:41:21 +0200 (CEST) Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id 82B0437B774 for ; Sun, 30 Apr 2000 14:40:31 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Sun, 30 Apr 2000 16:40:22 -0500 From: Richard Wackerbarth To: "Daniel O'Connor" Subject: Re: How about building modules along with the kernel? Date: Sun, 30 Apr 2000 16:40:21 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-arch@freebsd.org References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00043016402100.01312@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 30 Apr 2000, Daniel O'Connor wrote: > I think having *our* boot loader grok *other* OS's is a little silly. This isn't about the OS. It is about the FS. We already support a number of FS and can boot from many of them. > They have their own boot loaders :) It's not a question of booting MSDOS from a UFS disk, we already can boot MSDOS from a FAT disk.(to the extent that we call "their" loader from our multi-boot front end. The question has to do with the set of file systems that are acceptable for our root. On dual boot machines and removable media, we already support file systems that were not in the earlier Unix(tm) systems. As additional file systems become available, will we attempt to boot from them? For example, there are file systems that are explicitly designed for flash modules. It might be very nice to load the system from such a device. At the same time, the logic of the loader is becoming more complex. I think that it is appropriate to consider a "modularization" that separates the OS format from the FS format. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 1 5:41:54 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8A7C437B8AA for ; Mon, 1 May 2000 05:41:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA20078 for ; Mon, 1 May 2000 14:41:41 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA13215 for freebsd-arch@freebsd.org; Mon, 1 May 2000 14:41:41 +0200 (CEST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0D9E437B782 for ; Mon, 1 May 2000 05:39:14 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA81800; Mon, 1 May 2000 14:39:11 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Ben Smithurst Cc: arch@freebsd.org Subject: Re: fetch(1) References: <20000430011507.A22035@strontium.scientia.demon.co.uk> From: Dag-Erling Smorgrav Date: 01 May 2000 14:39:10 +0200 In-Reply-To: Ben Smithurst's message of "Sun, 30 Apr 2000 01:15:07 +0100" Message-ID: Lines: 17 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ben Smithurst writes: > I for one would rather at least -r were implemented before replacing the > current fetch(1). That's what I intended. Jordan's already made it quite clear that -r is a prerequisite. > Is your fetch(3)-based version available for download > anywhere? No up-to-date version. I have two slightly different versions on my home and work boxen and need to merge them before I can upload anything. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 1 13: 0:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2390037C1A1 for ; Mon, 1 May 2000 13:00:53 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA21179 for ; Mon, 1 May 2000 22:00:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA14180 for freebsd-arch@freebsd.org; Mon, 1 May 2000 22:00:30 +0200 (CEST) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id F366D37BFD5 for ; Mon, 1 May 2000 12:58:04 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA03608; Mon, 1 May 2000 13:00:15 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: fetch(1) In-reply-to: Your message of "29 Apr 2000 14:50:55 +0200." Date: Mon, 01 May 2000 13:00:15 -0700 Message-ID: <3605.957211215@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So, any arguments for or against importing it into -CURRENT? Yes, the fact that it's not fully compatible with the old. I'm sure you're eager to bring in a newer fetch(1), but you should still wait until it's a complete replacement before taking this important final step. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 5 14:22:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 65D8B37B7DA for ; Fri, 5 May 2000 14:22:54 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA03177; Fri, 5 May 2000 23:22:17 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Greg Lehey Cc: FreeBSD-arch@FreeBSD.org Subject: Re: Support for bootable Vinum file systems: please review In-reply-to: Your message of "Fri, 05 May 2000 12:21:00 +0930." <20000505122100.I32650@freebie.lemis.com> Date: Fri, 05 May 2000 23:22:17 +0200 Message-ID: <3175.957561737@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I've been testing vinum root file systems for a couple of months now, >and I'd like to commit the code. I'm attaching the patches, which you >can also access at http://www.FreeBSD.org/~grog/vinum-root.html. It looks good, but I think using devstat to find possible disks is wrong. The right way to do it is probably to link the "struct disk"s registered by the drivers with disk_creat() into a list which can be searched. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 5 14:47:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 755E437BCCE for ; Fri, 5 May 2000 14:47:40 -0700 (PDT) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id PAA58901; Fri, 5 May 2000 15:41:34 -0600 (MDT) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <200005052141.PAA58901@caspian.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: Greg Lehey , FreeBSD-arch@FreeBSD.ORG Subject: Re: Support for bootable Vinum file systems: please review In-Reply-To: Your message of "Fri, 05 May 2000 23:22:17 +0200." <3175.957561737@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 May 2000 15:41:34 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >It looks good, but I think using devstat to find possible disks is >wrong. I agree. Another thing that is ugly about this is the kludge in the partition table. I'd rather see us finally bite the bullet and move to an extensible disklabel scheme. So, in order to have a bootable vinum RAID 1 volume, your partition entry might look like this: Section 0 Section Size XXX bytes Section Type BSD Parition Info BSD Parition Specific info ... Section 1 Section Size XXX bytes Section Type Vinum Info Partition is Part 0 of X parts type RAID 1 etc. Reserved Space for additional Sections Actual partition data.... So, the bootstrap doesn't need to know how to interpret anything other than Section 0 and how to skip over other sections to find the start of data. Once the kernel is loaded, a vinum interrupt driven configuration hook can scan all known disklabel entries for its sections and build its plexes on the fly. The only additional piece of magic required is stealing root away from the booted off partition, but I'm sure Greg has already dealt with that. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat May 6 18:41:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0CEEC37B57A for ; Sat, 6 May 2000 18:41:11 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id VAA03551 for ; Sat, 6 May 2000 21:41:10 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 2 May 2000 21:19:38 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@FreeBSD.org Subject: Procedure for introducing new errno values? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ReSent-Date: Fri, 5 May 2000 18:59:44 -0400 (EDT) X-ReSent-From: robert X-ReSent-To: freebsd-arch@FreeBSD.org X-ReSent-Message-ID: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After some chat with various consumers of the extended attribute code, as well as interested parties in the Linux realm who are looking at providing a similar service over the Linux kernel, we've concluded that the current errno message range doesn't contain a value appropriate for ``Extended attribute not defined'' -- similar possibilities, such as ENOENT or ENODEV, do not uniquely describe the error condition and can be confusing. For example, ``File not found'' following a ``getextattr md5 /kernel'' suggests that /kernel was not found, not that the md5 attribute was not found. What is the correct procedure for adding new errno values? Presumably errno.8, src/sys/errno.h, as well as presumably some other files (perhaps in libc) for defining the string version, et al? I've also noticed that there is an errno.h in both /usr/include and /usr/include/sys. I am proposing EEXTATTR ("Extended attribute not defined"), which would be returned when a consumer of the VOP_GETEXTATTR() call attempted to retrieve an undefined attribute name. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat May 6 18:41:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B4FD737B62F for ; Sat, 6 May 2000 18:41:11 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id VAA03560 for ; Sat, 6 May 2000 21:41:11 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 4 May 2000 10:32:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@FreeBSD.org Cc: trustedbsd-discuss@TrustedBSD.org Subject: Proposed changes to suser() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ReSent-Date: Fri, 5 May 2000 19:00:09 -0400 (EDT) X-ReSent-From: robert X-ReSent-To: freebsd-arch@FreeBSD.org X-ReSent-Message-ID: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The purpose of this message is to identify some proposed changes from the TrustedBSD implementation that I'd like to commit to the FreeBSD source tree. As such, I'm sending this email to freebsd-arch, but CC'ing to trustedbsd-discuss. Currently, the FreeBSD process accounting mechanism provides a number of process flags, including the flag ASU. ASU is set when a process performs a ``super-user activity'' -- i.e., invokes privilege to access a file not normally permitted by permission checks, modifies privileged kernel objects (network configuration, ...), signals processes, et al. As part of the least-privilege POSIX.1e Capabilities support, there are now new ways to invoke privilege: calls not unlike suser() and suser_xxx() exist to check for specific capabilities -- cap_check() and cap_check_xxx(). This introduces a problem, as currently the ASU bit is set in suser_xxx() as the result of a successful call. The nature of the problem is actually fairly serious: ASU is currently set as the result of an access control check, and not as a result of the actual use of privilege. The current source base goes to enourmous trouble to avoid invoking suser() if the result could be an incorrectly set ASU bit. For example, in file system code where multiple access checks must occur (i.e., super-user privilege might be checked more than once), some of the checks are done by a direct uid==0 check. For example, this occurs in ufs_access() during file flag modification. As such, the problem is relevant even in the base source tree without new authorization mechanisms, but becomes particular relevant with such changes. The problem also becomes relevant once you throw fine-grained auditing into the picture: it's useful to be able to tell when any individual call succeeds as a result of privilege being invoked. To solve these problems, I'm currently working with a somewhat modified framework: the simple aspect is that suser_xxx() no longer sets the ASU bit, as with the cap_check_xxx() call. There's a new suser_used() call whose only action is to set the ASU bit for the process passed. These changes mean that all locations in the code where suser() is currently called need to be restructured to monitor the use of privilege, and then audit it at the end of their activity. Not surprisingly, this actually cleans up a number of pieces of code that currently are fairly unreadable as a result of the attempts not to use suser(). It also means that a number of suser() wrapper calls have to be updated to indicate whether privilege was used: for example, the checks used to determine if p1 can signal p2 all perform uid checks, and then suser checks. They must now be modified to return a privilege invoked variable to the caller for the purposes of the caller auditing use of privilege. In the future, we have plans to introduce a more general authorization framework, but this is still in the design stages. In the mean time, these suser() changes have the benefits of: cleaning up invocation of suser() code, allowing removal of many of the remaining uid==0 checks in the kernel, seperating authorization checks and monitoring of least privilege, and directly facilitating importing of capabilities support. I'd like to commit these patches in several phases. First, I'll commit the suser_used() code. Then I will restructure several access checks to make use of suser_used() resulting in redundant setting of the ASU bit (as well as temporarily gratuitously setting ASU in some situations). Finally, I will disable the ASU behavior in suser(). I'd like to integrate these changes slowly and with maximal inspection, as they will change security-sensitive access-control checks in a variety of kernel components: it is important that while introducing infrastructure for security improvements that we don't open up security holes. Patches for these changes will be available shortly. I am still catching the last few suser() calls. Third party modules making use of the suser() call will need to be changed to set ASU properly. Any comments? Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat May 6 20:44:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 3BBA337B5D8; Sat, 6 May 2000 20:44:34 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id UAA14995; Sat, 6 May 2000 20:40:52 -0700 (PDT) Message-Id: <200005070340.UAA14995@implode.root.com> To: Robert Watson Cc: freebsd-arch@FreeBSD.ORG, trustedbsd-discuss@TrustedBSD.org Subject: Re: Proposed changes to suser() In-reply-to: Your message of "Thu, 04 May 2000 10:32:06 EDT." From: David Greenman Reply-To: dg@root.com Date: Sat, 06 May 2000 20:40:52 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >kernel components: it is important that while introducing infrastructure >for security improvements that we don't open up security holes. > >Patches for these changes will be available shortly. I am still catching >the last few suser() calls. Third party modules making use of the suser() >call will need to be changed to set ASU properly. > >Any comments? Sounds pretty good to me, although suser_used said quickly is a bit of a tongue twister. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message