From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 10:06:24 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0662016A403; Mon, 1 Jan 2007 10:06:24 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id C01C313C441; Mon, 1 Jan 2007 10:06:23 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 837E45A1DDB; Mon, 1 Jan 2007 21:06:17 +1100 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 85ED58C02; Mon, 1 Jan 2007 21:06:16 +1100 (EST) Date: Mon, 1 Jan 2007 21:06:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Robert Watson In-Reply-To: <20061231153329.Y8131@fledge.watson.org> Message-ID: <20070101205016.U3544@epsplex.bde.org> References: <459745DA.1010801@freebsd.org> <20061231153329.Y8131@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Colin Percival , "freebsd-arch@freebsd.org" Subject: Re: default value of security.bsd.hardlink_check_[ug]id X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2007 10:06:24 -0000 On Sun, 31 Dec 2006, Robert Watson wrote: > I'm not entirely happy with the current implementation, FWIW. I'd like > can_hardlink to be implemented in the per file system code, possibly by > invoking a common routine of this sort, avoiding the extra call to > VOP_GETATTR(), and allowing file systems not implementing ownership in > traditional ways (msdosfs, etc) to do whatever makes sense in their context. > On the whole, these sorts of decisions are made in each file system, often > using common code (perhaps centralized), and not at the VFS layer. I think it also has wrong semantics. It denies privilege based on non-ownership, while everything that uses vaccess() grants privilege based on ownership. This gives the surprising behaviour that if hardlink_check_gid = 1, the owner of a file can do anything to the file except link to it in cases where the group of the file isn't in the caller's group list (and no immutable but is set). Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 10:41:34 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 877D816A40F; Mon, 1 Jan 2007 10:41:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5712413C44C; Mon, 1 Jan 2007 10:41:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6290948681; Mon, 1 Jan 2007 05:41:33 -0500 (EST) Date: Mon, 1 Jan 2007 10:41:33 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Evans In-Reply-To: <20070101205016.U3544@epsplex.bde.org> Message-ID: <20070101103544.T7974@fledge.watson.org> References: <459745DA.1010801@freebsd.org> <20061231153329.Y8131@fledge.watson.org> <20070101205016.U3544@epsplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Colin Percival , "freebsd-arch@freebsd.org" Subject: Re: default value of security.bsd.hardlink_check_[ug]id X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2007 10:41:34 -0000 On Mon, 1 Jan 2007, Bruce Evans wrote: > On Sun, 31 Dec 2006, Robert Watson wrote: > >> I'm not entirely happy with the current implementation, FWIW. I'd like >> can_hardlink to be implemented in the per file system code, possibly by >> invoking a common routine of this sort, avoiding the extra call to >> VOP_GETATTR(), and allowing file systems not implementing ownership in >> traditional ways (msdosfs, etc) to do whatever makes sense in their >> context. On the whole, these sorts of decisions are made in each file >> system, often using common code (perhaps centralized), and not at the VFS >> layer. > > I think it also has wrong semantics. It denies privilege based on > non-ownership, while everything that uses vaccess() grants privilege based > on ownership. This gives the surprising behaviour that if > hardlink_check_gid = 1, the owner of a file can do anything to the file > except link to it in cases where the group of the file isn't in the caller's > group list (and no immutable but is set). Yes, I think you're right. Per our earlier thread on the structure of privilege checks on arch@, security checks generally shold look something like this: error = dac_check(cred, object); if (error) { error = priv_check(cred, privilege); if (error) return (error); } The requirement for ownership or privilege for linking is part of the DAC check in this structure. Operations seem to fall down into three categories: - Operations always requiring privilege. - Operations requiring ownership or privilege. - Operations requiring rights be granted via the ACL or privilege. There may be a few edge cases requiring ownership, ACL, or privilege, but these may also be bugs. I think we should always allow linking rights for the owner and for privilege, and optionally also for the group or everyone. So perhaps we want a linking mib entry that selects one of the following "levels" for hard linking: - Privilege required. - Ownership or privilege required. - Matching group or ownership or privilege required. - Allowed for everyone. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 18:39:45 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 438D816A412 for ; Mon, 1 Jan 2007 18:39:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E507E13C45A for ; Mon, 1 Jan 2007 18:39:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l01IbosV080559 for ; Mon, 1 Jan 2007 11:37:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 01 Jan 2007 11:38:01 -0700 (MST) Message-Id: <20070101.113801.818271922.imp@bsdimp.com> To: arch@FreeBSD.org From: "M. Warner Losh" X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 01 Jan 2007 11:37:50 -0700 (MST) Cc: Subject: usb modems and com devices into GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2007 18:39:45 -0000 I'd like to place the following in GENERIC. We're getting more and more questions about these devices that we wouldn't be getting if we had them compiled in by default. The really imporant ones are marked with a '*' below device ucom # * device umodem # * device umct device uark device ubsa device ubser device uftdi # * device uplcom # * device uvisor device uvscom the cost isn's so much, and we can filter them out from the installation kernel if size is an issue. Comments? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 19:13:01 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB72E16A407 for ; Mon, 1 Jan 2007 19:13:00 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id 44A6213C45B for ; Mon, 1 Jan 2007 19:13:00 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 61590D4C32; Mon, 1 Jan 2007 19:41:38 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWjcYjvBzU3Q; Mon, 1 Jan 2007 19:41:33 +0100 (CET) Received: from thunderstone.rink.nu (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id 55C7FD4C30; Mon, 1 Jan 2007 19:41:33 +0100 (CET) Received: (from rink@localhost) by thunderstone.rink.nu (8.13.8/8.13.8/Submit) id l01IfX5S091895; Mon, 1 Jan 2007 19:41:33 +0100 (CET) (envelope-from rink) Date: Mon, 1 Jan 2007 19:41:33 +0100 From: Rink Springer To: "M. Warner Losh" Message-ID: <20070101184133.GA86039@rink.nu> References: <20070101.113801.818271922.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20070101.113801.818271922.imp@bsdimp.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: arch@FreeBSD.org Subject: Re: usb modems and com devices into GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2007 19:13:01 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Warner, On Mon, Jan 01, 2007 at 11:38:01AM -0700, M. Warner Losh wrote: > I'd like to place the following in GENERIC. We're getting more and > more questions about these devices that we wouldn't be getting if we > had them compiled in by default. The really imporant ones are marked > with a '*' below >=20 > device ucom # * > device umodem # * > device umct > device uark > device ubsa > device ubser > device uftdi # * > device uplcom # * > device uvisor > device uvscom >=20 > the cost isn's so much, and we can filter them out from the > installation kernel if size is an issue. >=20 > Comments? >=20 > Warner Sounds good to me. I usually kldload(8) some of this for my uplcom(4), but it would not hurt having this in GENERIC. I'm all in favor. --=20 Rink P.W. Springer - http://rink.nu "It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it." - Darth Traya --nFreZHaLTZJo0R7j Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIJawYJKoZIhvcNAQcCoIIJXDCCCVgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuIwggObMIIDBKADAgECAhAiuN7bs9pg6t3I0n6G5OOTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjExMDgwOTI2 NTNaFw0wNzExMDgwOTI2NTNaMIHSMREwDwYDVQQEEwhTcHJpbmdlcjEaMBgGA1UEKhMRUmlu ayBQZXRlciBXeWNoZXIxIzAhBgNVBAMTGlJpbmsgUGV0ZXIgV3ljaGVyIFNwcmluZ2VyMRsw GQYJKoZIhvcNAQkBFgxtYWlsQHJpbmsubnUxHzAdBgkqhkiG9w0BCQEWEHJpbmtAZnJlZWJz ZC5vcmcxIDAeBgkqhkiG9w0BCQEWEXJpbmtAaWwuZm9udHlzLm5sMRwwGgYJKoZIhvcNAQkB Fg1yaW5rQHN0YWNrLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxryGDfel YzzENX7wodkbVY1NALfaiPfNEG10YjD8ZWdK9zkN26Tc878Shbqapq0KYFD8TACGfEhKoMvo qbf0PHAS/gNYr81Arqa9FRPUfzvtDE/cMbhvI+p7ufBITyYnPJp9MUD72iT+DohRR2ISVi3i NAEgDuSbYYNxctnvXqU6O6EPy3mzoFPDoiOQwBfVtFrjxBbND9BUK2bjtUyGt4x8I/Vulzrt qLPTokva+b97DHRgbCA/aLLYIrU6QoqOFJ8GrAbro/FZLYh4m1oJk3FEHVQOKkk7xzIaFmmP QGJRL8m6nrIZFTrQ+X2wmzfLD55K/UiqbekOuMiWbY9EbwIDAQABo10wWzBLBgNVHREERDBC gQxtYWlsQHJpbmsubnWBEHJpbmtAZnJlZWJzZC5vcmeBEXJpbmtAaWwuZm9udHlzLm5sgQ1y aW5rQHN0YWNrLm5sMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAIfIcieRjePBA wjZqvOdGpyPcNDnK/ubeQSTV5Y4AHWxm1sXhQxB/XrQ3RVdz1qDnBRL1AjkEBAl8e9+am4s6 D6TaSlmJeNXn6ZPJTQecisz3M+AKiMckShM3oAeUi0ktn1yNYR+hz5aQN612XT5OZRYznJVZ kPf1DiA2RVVyz+MwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQG EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNV BAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAw WhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBly YLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJo dHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3 h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYICUTCCAk0CAQEwdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECK43tuz2mDq3cjS fobk45MwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzAxMDExODQxMzNaMCMGCSqGSIb3DQEJBDEWBBStFXomM58wIC2d3oVaf4ig jDJ/fDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCN QTIPA8io2pz/LmcPTYh9X09Q7Z/3C3h3Oepx2aRPi2BqpIImW9QIk7/ollM4CfDIj2+CZH8q ZDbCpzqg7Vv8NmWtdT/zZCY8q3FaLpTm2fdhE5BXla2JZv/komNMn/Qf2NFgBFC2q1df+quX /cKvxnMsCbuimmvsbtlKsophHNW9mCm608D0aNTFPvBlbFv+EGMivtJJ5xbgWuRj00C525sd /RkdC7hAamQ4JIXSYAP0kM84Q1yR69aP8bJDOGWQAE2XeEL2uGAES9nr0y0siyb8kMVLTL+W /ZvtwIQgUpoVv6AeExkhnqv33Uzfu1/mjKh5Za2dpq45ViH/nBBJ --nFreZHaLTZJo0R7j-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 2 04:54:28 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A079116A407 for ; Tue, 2 Jan 2007 04:54:28 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd4mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 75DD713C448 for ; Tue, 2 Jan 2007 04:54:28 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd5mr1so.prod.shaw.ca (pd5mr1so-qfe3.prod.shaw.ca [10.0.141.232]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JB800M5A5MRIJ40@l-daemon> for freebsd-arch@freebsd.org; Mon, 01 Jan 2007 21:54:27 -0700 (MST) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd5mr1so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JB800CRM5MRHL51@pd5mr1so.prod.shaw.ca> for freebsd-arch@freebsd.org; Mon, 01 Jan 2007 21:54:27 -0700 (MST) Received: from hexahedron.daemonology.net ([24.82.18.31]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JB8009VH5MPHEA0@l-daemon> for freebsd-arch@freebsd.org; Mon, 01 Jan 2007 21:54:26 -0700 (MST) Received: (qmail 49244 invoked from network); Tue, 02 Jan 2007 04:54:20 +0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; Tue, 02 Jan 2007 04:54:20 +0000 Date: Mon, 01 Jan 2007 20:54:20 -0800 From: Colin Percival In-reply-to: <20061231124431.GG97921@submonkey.net> To: Ceri Davies , Colin Percival , "freebsd-arch@freebsd.org" Message-id: <4599E57C.5090904@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.94.0.0 References: <459745DA.1010801@freebsd.org> <20061231124431.GG97921@submonkey.net> User-Agent: Thunderbird 1.5.0.9 (X11/20061227) Cc: Subject: Re: default value of security.bsd.hardlink_check_[ug]id X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2007 04:54:28 -0000 Ceri Davies wrote: > On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote: >> I'd like to make security.bsd.hardlink_check_[ug]id default to 1, starting >> with FreeBSD 7.x. This would make it impossible for a user to create a hard >> link to a file which he does not own. > > a) you have provided no rationale; Allowing users to create hard links to files which they do not own creates problems: 1. If disk quotas are enabled, a user can waste another user's disk quota by making it impossible for said other user to delete files. 2. It becomes difficult to apply security fixes for issues involving setuid binaries, since a local attacker could create hard links to all the setuid binaries (or at least those on filesystems where he can write somewhere) and wait for a security issue to be found. I honestly can't see why it was ever possible for users to create hard links to files which they don't own; hopefully someone can provide the historical background and tell me if the original reasons (whatever they were) still apply. If it isn't possible to outlaw such hard linking entirely, I'd like to make it impossible by default for (a) a user to create a hard link to a setuid file which they do not own, and (b) a user to create a hard link to a setgid file if they are not in the right group, since these are the important cases for security. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Tue Jan 2 11:05:54 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E41416A412; Tue, 2 Jan 2007 11:05:54 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.freebsd.org (Postfix) with ESMTP id 2C59A13C4AC; Tue, 2 Jan 2007 11:05:54 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.64 (FreeBSD)) (envelope-from ) id 1H1hSr-000138-5y; Tue, 02 Jan 2007 11:05:53 +0000 Date: Tue, 2 Jan 2007 11:05:53 +0000 From: Ceri Davies To: Colin Percival Message-ID: <20070102110552.GN97921@submonkey.net> Mail-Followup-To: Ceri Davies , Colin Percival , "freebsd-arch@freebsd.org" References: <459745DA.1010801@freebsd.org> <20061231124431.GG97921@submonkey.net> <4599E57C.5090904@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B92bTrfKjyax39gr" Content-Disposition: inline In-Reply-To: <4599E57C.5090904@freebsd.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Ceri Davies Cc: "freebsd-arch@freebsd.org" Subject: Re: default value of security.bsd.hardlink_check_[ug]id X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2007 11:05:54 -0000 --B92bTrfKjyax39gr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 01, 2007 at 08:54:20PM -0800, Colin Percival wrote: > Ceri Davies wrote: > > On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote: > >> I'd like to make security.bsd.hardlink_check_[ug]id default to 1, star= ting > >> with FreeBSD 7.x. This would make it impossible for a user to create = a hard > >> link to a file which he does not own. > >=20 > > a) you have provided no rationale; >=20 > Allowing users to create hard links to files which they do not own creates > problems: > 1. If disk quotas are enabled, a user can waste another user's disk quota= by > making it impossible for said other user to delete files. > 2. It becomes difficult to apply security fixes for issues involving setu= id > binaries, since a local attacker could create hard links to all the setuid > binaries (or at least those on filesystems where he can write somewhere) = and > wait for a security issue to be found. >=20 > I honestly can't see why it was ever possible for users to create hard li= nks > to files which they don't own; hopefully someone can provide the historic= al > background and tell me if the original reasons (whatever they were) still > apply. Notwithstanding the lack of documentation of the sysctls, I'm happy; thanks for the follow up. I've changed my Solaris 10 "crash" box to remove this ability from the basic set [1]; I'll report if anything seems to go awry with it. Ceri [1] If anyone else would like to play along, edit /etc/security/policy.conf to set PRIV_DEFAULT to basic,!file_link_any and reboot. --=20 That must be wonderful! I don't understand it at all. -- Moliere --B92bTrfKjyax39gr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFmjyQocfcwTS3JF8RAhsNAJ9bhjsLri5u7Qun1oQ0mbLWggHJKQCdFtG6 HWhhIgX/ahFSAZxZycuyYsQ= =QFrj -----END PGP SIGNATURE----- --B92bTrfKjyax39gr-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 2 23:07:55 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F153716A403; Tue, 2 Jan 2007 23:07:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C6AF213C45E; Tue, 2 Jan 2007 23:07:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 72B0049717; Tue, 2 Jan 2007 18:07:55 -0500 (EST) Date: Tue, 2 Jan 2007 23:07:55 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Colin Percival In-Reply-To: <4599E57C.5090904@freebsd.org> Message-ID: <20070102230111.M7974@fledge.watson.org> References: <459745DA.1010801@freebsd.org> <20061231124431.GG97921@submonkey.net> <4599E57C.5090904@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ceri Davies , "freebsd-arch@freebsd.org" Subject: Re: default value of security.bsd.hardlink_check_[ug]id X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2007 23:07:56 -0000 On Mon, 1 Jan 2007, Colin Percival wrote: > Ceri Davies wrote: >> On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote: >>> I'd like to make security.bsd.hardlink_check_[ug]id default to 1, starting >>> with FreeBSD 7.x. This would make it impossible for a user to create a hard >>> link to a file which he does not own. >> >> a) you have provided no rationale; > > Allowing users to create hard links to files which they do not own creates > problems: > 1. If disk quotas are enabled, a user can waste another user's disk quota by > making it impossible for said other user to delete files. > 2. It becomes difficult to apply security fixes for issues involving setuid > binaries, since a local attacker could create hard links to all the setuid > binaries (or at least those on filesystems where he can write somewhere) and > wait for a security issue to be found. I find the second argument here most compelling, and use it as an example frequently when complaining about hard links. Hard links also one of the elements that makes it difficult to usefully generate names for file system objects, due to their introducing ambiguity. > I honestly can't see why it was ever possible for users to create hard links > to files which they don't own; hopefully someone can provide the historical > background and tell me if the original reasons (whatever they were) still > apply. It's generally consistent with the world view that says names of objects are property of the directory they appear in. In terms of history: remember that before there was rename(), there were link() and unlink(), and if you want to give users who own directories the right to rename within those directories, that required the ability to link() and unlink(). That model is quite consistent, but interacts poorly with the way users, and especially administrators, expect the system to work. > If it isn't possible to outlaw such hard linking entirely, I'd like to make > it impossible by default for > (a) a user to create a hard link to a setuid file which they do not own, and > (b) a user to create a hard link to a setgid file if they are not in the right > group, > since these are the important cases for security. I think we should give the change in defaults (after cleaning up the implementation per bde's and my comments) for the sysctl a trial run in 7-CURRENT for a few months and see what breaks. If we get lots of complaints, we can back out the change, refine it, etc. History suggests that this isn't a foolproof way to find problems (remember how long it took to shake out changes in signaling protection), but it may well turn up something useful. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 02:33:29 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3ACE016A407 for ; Thu, 4 Jan 2007 02:33:29 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id C4E7F13C442 for ; Thu, 4 Jan 2007 02:33:28 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so4734264uge for ; Wed, 03 Jan 2007 18:33:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=m79GclQpfhApQLNCK+zhHWVLfzSEx6mzrcTJ4q4b2KTctFXfTeQrqAlP8TN7MYFsSdM4KSSyD2Yeqr2OvpAVFoHkclgJQ2lclTYS3Vx47MGEufEf0vkgjccOKiQ1OA1oiS46hQ+vyaW98DGJ5jMXtOuMgRvi214Nw3FAYrCxDWg= Received: by 10.67.89.5 with SMTP id r5mr27739997ugl.1167876340690; Wed, 03 Jan 2007 18:05:40 -0800 (PST) Received: from roadrunner.q.local ( [85.180.149.2]) by mx.google.com with ESMTP id u6sm33129750uge.2007.01.03.18.05.39; Wed, 03 Jan 2007 18:05:40 -0800 (PST) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.8/8.13.8) with ESMTP id l03Kwid8091615; Wed, 3 Jan 2007 21:58:44 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.8/8.13.8/Submit) id l03Kwf1D091055; Wed, 3 Jan 2007 21:58:41 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Wed, 3 Jan 2007 21:58:41 +0100 From: Ulrich Spoerlein To: "M. Warner Losh" Message-ID: <20070103205841.GB85200@roadrunner.q.local> Mail-Followup-To: "M. Warner Losh" , arch@FreeBSD.org References: <20070101.113801.818271922.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070101.113801.818271922.imp@bsdimp.com> Cc: arch@FreeBSD.org Subject: Re: usb modems and com devices into GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 02:33:29 -0000 M. Warner Losh wrote: > I'd like to place the following in GENERIC. We're getting more and > more questions about these devices that we wouldn't be getting if we > had them compiled in by default. The really imporant ones are marked > with a '*' below > > device ucom # * > device umodem # * > device umct > device uark > device ubsa > device ubser > device uftdi # * > device uplcom # * > device uvisor > device uvscom > > the cost isn's so much, and we can filter them out from the > installation kernel if size is an issue. > > Comments? Hi Warner, why not do it the other way round? Keep them out of GENERIC, but have loader(8) load some of the most used modules (snd_driver!) per default. That way, people can easily disable these (without needing to recompile). I mean, what point is there in the whole KLD infrastructure, if we are going to add every device into GENERIC anyway? Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 03:36:49 2007 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C006E16A403 for ; Thu, 4 Jan 2007 03:36:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7F32613C457 for ; Thu, 4 Jan 2007 03:36:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l043XsWe039223; Wed, 3 Jan 2007 20:33:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 03 Jan 2007 20:34:03 -0700 (MST) Message-Id: <20070103.203403.63053841.imp@bsdimp.com> To: uspoerlein@gmail.com From: "M. Warner Losh" In-Reply-To: <20070103205841.GB85200@roadrunner.q.local> References: <20070101.113801.818271922.imp@bsdimp.com> <20070103205841.GB85200@roadrunner.q.local> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 03 Jan 2007 20:33:55 -0700 (MST) Cc: arch@FreeBSD.org Subject: Re: usb modems and com devices into GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 03:36:49 -0000 In message: <20070103205841.GB85200@roadrunner.q.local> Ulrich Spoerlein writes: : M. Warner Losh wrote: : > I'd like to place the following in GENERIC. We're getting more and : > more questions about these devices that we wouldn't be getting if we : > had them compiled in by default. The really imporant ones are marked : > with a '*' below : > : > device ucom # * : > device umodem # * : > device umct : > device uark : > device ubsa : > device ubser : > device uftdi # * : > device uplcom # * : > device uvisor : > device uvscom : > : > the cost isn's so much, and we can filter them out from the : > installation kernel if size is an issue. : > : > Comments? : : Hi Warner, : : why not do it the other way round? Keep them out of GENERIC, but have : loader(8) load some of the most used modules (snd_driver!) per default. : : That way, people can easily disable these (without needing to : recompile). : : I mean, what point is there in the whole KLD infrastructure, if we are : going to add every device into GENERIC anyway? Because the meta-data necessary to know which module to load doesn't presently exist in a standardized enough form to make this a viable option. Each driver does its own thing to match the cards, and there's no easy way to know that any given usb device needs module foo. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 07:52:32 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6532B16A40F for ; Thu, 4 Jan 2007 07:52:32 +0000 (UTC) (envelope-from freebsd-arch@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.freebsd.org (Postfix) with ESMTP id EF15F13C458 for ; Thu, 4 Jan 2007 07:52:31 +0000 (UTC) (envelope-from freebsd-arch@dino.sk) Received: from lex.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by bsd.dino.sk with esmtp; Thu, 04 Jan 2007 08:17:43 +0100 id 00000033.459CAA17.0000AE6C From: Milan Obuch To: freebsd-arch@freebsd.org Date: Thu, 4 Jan 2007 07:57:33 +0100 User-Agent: KMail/1.9.4 References: <20070101.113801.818271922.imp@bsdimp.com> <20070103205841.GB85200@roadrunner.q.local> <20070103.203403.63053841.imp@bsdimp.com> In-Reply-To: <20070103.203403.63053841.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701040757.34880.freebsd-arch@dino.sk> Subject: Re: usb modems and com devices into GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 07:52:32 -0000 On Thursday 04 January 2007 04:34, M. Warner Losh wrote: > In message: <20070103205841.GB85200@roadrunner.q.local> > > Ulrich Spoerlein writes: > : M. Warner Losh wrote: > : > I'd like to place the following in GENERIC. We're getting more and > : > more questions about these devices that we wouldn't be getting if we > : > had them compiled in by default. The really imporant ones are marked > : > with a '*' below > : > > : > device ucom # * > : > device umodem # * > : > device umct > : > device uark > : > device ubsa > : > device ubser > : > device uftdi # * > : > device uplcom # * > : > device uvisor > : > device uvscom > : > > : > the cost isn's so much, and we can filter them out from the > : > installation kernel if size is an issue. > : > > : > Comments? > : > : Hi Warner, > : > : why not do it the other way round? Keep them out of GENERIC, but have > : loader(8) load some of the most used modules (snd_driver!) per default. > : > : That way, people can easily disable these (without needing to > : recompile). > : > : I mean, what point is there in the whole KLD infrastructure, if we are > : going to add every device into GENERIC anyway? > > Because the meta-data necessary to know which module to load doesn't > presently exist in a standardized enough form to make this a viable > option. Each driver does its own thing to match the cards, and > there's no easy way to know that any given usb device needs module > foo. > > Warner > Currently, /boot/loader.conf after fresh installation is empty. If it contains lines ucom_load="YES" umodem_load="YES" uftdi_load="YES" uplcom="YES" you will both get the desired effect and need not to expand included device list. Actually, we could move the other way - instead of having big kernel (relatively) with many devices compiled in, we could keep the drivers as .ko's and let the loader load them. Install-and-forget-about-it type of users will get what it wants, more advanced ones and tweakers could make first optimization to some level without need for recompile. I feel this way GENERIC could be more universal, in some sense. That said, I am not against including anything in GENERIC, but currently really there is no point building/installing kernel modules - only acpi.ko is regularly used in default configuration, to my knowledge. Regards, Milan -- No need to mail me directly. Just reply to mailing list, please. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 18:22:30 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82B9416A415 for ; Thu, 4 Jan 2007 18:22:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 0B20013C448 for ; Thu, 4 Jan 2007 18:22:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l04HjGsK031320; Thu, 4 Jan 2007 12:45:16 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 4 Jan 2007 11:21:01 -0500 User-Agent: KMail/1.9.1 References: <20070101.113801.818271922.imp@bsdimp.com> <20070103205841.GB85200@roadrunner.q.local> In-Reply-To: <20070103205841.GB85200@roadrunner.q.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701041121.02455.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 04 Jan 2007 12:45:16 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2413/Thu Jan 4 04:46:27 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Ulrich Spoerlein Subject: Re: usb modems and com devices into GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 18:22:30 -0000 On Wednesday 03 January 2007 15:58, Ulrich Spoerlein wrote: > M. Warner Losh wrote: > > I'd like to place the following in GENERIC. We're getting more and > > more questions about these devices that we wouldn't be getting if we > > had them compiled in by default. The really imporant ones are marked > > with a '*' below > > > > device ucom # * > > device umodem # * > > device umct > > device uark > > device ubsa > > device ubser > > device uftdi # * > > device uplcom # * > > device uvisor > > device uvscom > > > > the cost isn's so much, and we can filter them out from the > > installation kernel if size is an issue. > > > > Comments? > > Hi Warner, > > why not do it the other way round? Keep them out of GENERIC, but have > loader(8) load some of the most used modules (snd_driver!) per default. > > That way, people can easily disable these (without needing to > recompile). > > I mean, what point is there in the whole KLD infrastructure, if we are > going to add every device into GENERIC anyway? It works great when you are developing a driver that lives in a module. :) The point is to give people tools to use, it's up to different people to use them as they see fit. I pretty much never use kernel modules (except for either working on a driver or test modules I write) but use static kernels since kernel debugging tends to be simpler when you avoid modules. It can also be a larger pain to manage if you are administering a lot of machines. You also then have the extra task of making sure kernel and modules are always in sync ABI-wise (a static kernel is always self-consistent). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 19:25:08 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60A8F16A407 for ; Thu, 4 Jan 2007 19:25:08 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id 255C013C44B for ; Thu, 4 Jan 2007 19:25:08 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1H2Xu9-00061u-Mh for freebsd-arch@freebsd.org; Thu, 04 Jan 2007 14:05:33 -0500 Date: Thu, 4 Jan 2007 14:05:33 -0500 From: Gary Palmer To: freebsd-arch@freebsd.org Message-ID: <20070104190533.GB97624@in-addr.com> Mail-Followup-To: freebsd-arch@freebsd.org References: <20070101.113801.818271922.imp@bsdimp.com> <20070103205841.GB85200@roadrunner.q.local> <200701041121.02455.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701041121.02455.jhb@freebsd.org> Subject: Re: usb modems and com devices into GENERIC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2007 19:25:08 -0000 On Thu, Jan 04, 2007 at 11:21:01AM -0500, John Baldwin wrote: > On Wednesday 03 January 2007 15:58, Ulrich Spoerlein wrote: > > M. Warner Losh wrote: > > > I'd like to place the following in GENERIC. We're getting more and > > > more questions about these devices that we wouldn't be getting if we > > > had them compiled in by default. The really imporant ones are marked > > > with a '*' below > > > > > > device ucom # * > > > device umodem # * > > > device umct > > > device uark > > > device ubsa > > > device ubser > > > device uftdi # * > > > device uplcom # * > > > device uvisor > > > device uvscom > > > > > > the cost isn's so much, and we can filter them out from the > > > installation kernel if size is an issue. > > > > > > Comments? > > > > Hi Warner, > > > > why not do it the other way round? Keep them out of GENERIC, but have > > loader(8) load some of the most used modules (snd_driver!) per default. > > > > That way, people can easily disable these (without needing to > > recompile). > > > > I mean, what point is there in the whole KLD infrastructure, if we are > > going to add every device into GENERIC anyway? > > It works great when you are developing a driver that lives in a module. :) > The point is to give people tools to use, it's up to different people to > use them as they see fit. I pretty much never use kernel modules (except > for either working on a driver or test modules I write) but use static > kernels since kernel debugging tends to be simpler when you avoid modules. > It can also be a larger pain to manage if you are administering a lot of > machines. You also then have the extra task of making sure kernel and > modules are always in sync ABI-wise (a static kernel is always > self-consistent). I think using KLD more in our installer image makes a lot of sense. It would allow people an option to not load USB modules if there is a problem on their system that prevents proper installation with the modules present. I'd probably swing more on doing it in the loader menu somehow than using loader.conf. Sound drivers can probably be handed through devd as loading those dymanically works much better than the USB stack. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 04:53:08 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 880CE16A403 for ; Fri, 5 Jan 2007 04:53:08 +0000 (UTC) (envelope-from petergroerii@yahoo.com) Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [206.18.177.53]) by mx1.freebsd.org (Postfix) with ESMTP id 6434713C442 for ; Fri, 5 Jan 2007 04:53:08 +0000 (UTC) (envelope-from petergroerii@yahoo.com) Received: from athlon64 (c-76-17-95-244.hsd1.ga.comcast.net[76.17.95.244]) by comcast.net (alnrmhc13) with SMTP id <20070105043811b1300q8q7ue>; Fri, 5 Jan 2007 04:38:12 +0000 From: "Peter Groer II" To: Date: Thu, 4 Jan 2007 23:37:38 -0500 Message-ID: <000501c73083$40ef44a0$c2cdcde0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AccwgzqGBEFjBvgjS1K3yqlZVECmyA== Content-Language: en-us X-Mailman-Approved-At: Fri, 05 Jan 2007 05:33:56 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Any hopes for a BSD for the new Cell Chip? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: petergroerii@yahoo.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2007 04:53:08 -0000 Any hopes for a BSD for the new Cell Chip from Sony/IBM/Toshiba ? Thanks, Peter Groer II From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 14:41:01 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64C8D16A403 for ; Fri, 5 Jan 2007 14:41:01 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id E0E9013C455 for ; Fri, 5 Jan 2007 14:41:00 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l05ES8sh048518; Fri, 5 Jan 2007 08:28:08 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l05ES8Oe048517; Fri, 5 Jan 2007 08:28:08 -0600 (CST) (envelope-from brooks) Date: Fri, 5 Jan 2007 08:28:08 -0600 From: Brooks Davis To: Peter Groer II Message-ID: <20070105142808.GA48496@lor.one-eyed-alien.net> References: <000501c73083$40ef44a0$c2cdcde0$@com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <000501c73083$40ef44a0$c2cdcde0$@com> User-Agent: Mutt/1.5.11 Cc: freebsd-arch@freebsd.org Subject: Re: Any hopes for a BSD for the new Cell Chip? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2007 14:41:01 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 04, 2007 at 11:37:38PM -0500, Peter Groer II wrote: > Any hopes for a BSD for the new Cell Chip from Sony/IBM/Toshiba ? The first step would be a PowerPC 64-bit port. Once that's done, my understanding is that the rest is easy, though supporting a traditional permission and execution model is impractical due to the vast amount of state that must be context switched. -- Brooks --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFnmB3XY6L6fI4GtQRAiZMAJ9WbNEudbcxwQDn6O+ntfniko9JIQCfe63c WOSja/VqU0docuZD7GTuL78= =NlRc -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 15:05:05 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC10216A417 for ; Fri, 5 Jan 2007 15:05:05 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 66FC113C46A for ; Fri, 5 Jan 2007 15:05:04 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H2pWy-0007z6-AC for freebsd-arch@freebsd.org; Fri, 05 Jan 2007 14:54:48 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Jan 2007 14:54:48 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Jan 2007 14:54:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Fri, 05 Jan 2007 14:54:36 +0100 Lines: 6 Message-ID: References: <000501c73083$40ef44a0$c2cdcde0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <000501c73083$40ef44a0$c2cdcde0$@com> Sender: news Subject: Re: Any hopes for a BSD for the new Cell Chip? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2007 15:05:05 -0000 Peter Groer II wrote: > Any hopes for a BSD for the new Cell Chip from Sony/IBM/Toshiba ? > Very much! Just inform us when you're ready to start and you'll receive generous support :) From owner-freebsd-arch@FreeBSD.ORG Sat Jan 6 16:45:08 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 296C716A40F for ; Sat, 6 Jan 2007 16:45:08 +0000 (UTC) (envelope-from cykyc@yahoo.com) Received: from web56107.mail.re3.yahoo.com (web56107.mail.re3.yahoo.com [216.252.110.201]) by mx1.freebsd.org (Postfix) with SMTP id C4E3713C441 for ; Sat, 6 Jan 2007 16:45:07 +0000 (UTC) (envelope-from cykyc@yahoo.com) Received: (qmail 27094 invoked by uid 60001); 6 Jan 2007 16:18:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=29CFD0Uc0iTRzB1M0fIoNVYFTWZosjM0LamsoLbYJXTrDqBSylqmusTckEkTP5B/E1mVsrzeGme4MNWEaewJhFZxHhymz9hwSNGpdGLmEbrWJDJ4hcvtNi+eLzQeHmU34pS/gnAzm2PmGtlH2mjoMKbdKNZIdzVvJ1nOlxGSx4w=; X-YMail-OSG: q5.0fg8VM1mdL0eB.uJFvw0_vhvXv9oK.wqmr0dfzFb6LfBXDtPEhqFN7HL2sa3bSSgBlwhfooNutRpRG6uvjoP6m7wolaMqw11TBLCc69G4iLJ9fifRhMBnEsuqAG0LZ.gHzW8kBis.8Jtt0XGDvzH7kfEY_DcEIlaaADGJxg5nZ1rxb9i1EGpDKU5g Received: from [209.98.139.33] by web56107.mail.re3.yahoo.com via HTTP; Sat, 06 Jan 2007 08:18:26 PST Date: Sat, 6 Jan 2007 08:18:26 -0800 (PST) From: Jon Passki To: Robert Watson , Colin Percival In-Reply-To: <20070102230111.M7974@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <77286.26791.qm@web56107.mail.re3.yahoo.com> Cc: Ceri Davies , "freebsd-arch@freebsd.org" Subject: Re: default value of security.bsd.hardlink_check_[ug]id X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cykyc@yahoo.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 16:45:08 -0000 --- Robert Watson wrote: > > On Mon, 1 Jan 2007, Colin Percival wrote: > > > Ceri Davies wrote: > >> On Sat, Dec 30, 2006 at 09:08:42PM -0800, Colin Percival wrote: > >>> I'd like to make security.bsd.hardlink_check_[ug]id default to 1, > starting > >>> with FreeBSD 7.x. This would make it impossible for a user to > create a hard > >>> link to a file which he does not own. > >> > >> a) you have provided no rationale; > > > > Allowing users to create hard links to files which they do not own > creates > > problems: > > 1. If disk quotas are enabled, a user can waste another user's disk > quota by > > making it impossible for said other user to delete files. > > 2. It becomes difficult to apply security fixes for issues > involving setuid > > binaries, since a local attacker could create hard links to all the > setuid > > binaries (or at least those on filesystems where he can write > somewhere) and > > wait for a security issue to be found. > > I find the second argument here most compelling, and use it as an > example > frequently when complaining about hard links. Hard links also one of > the > elements that makes it difficult to usefully generate names for file > system > objects, due to their introducing ambiguity. Or this goofy one: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/89589 Btw, OpenBSD does not allow this behavior but NetBSD does. At a minimum, if the user cannot even copy a file, he or she ought not to hard link the file. This behaviour, though, was permitted the last time I checked. Cheers, Jon __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-arch@FreeBSD.ORG Sat Jan 6 19:32:24 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 010C016A412 for ; Sat, 6 Jan 2007 19:32:24 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from heave.ugcs.caltech.edu (heave.ugcs.caltech.edu [131.215.176.104]) by mx1.freebsd.org (Postfix) with ESMTP id E219113C471 for ; Sat, 6 Jan 2007 19:32:23 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by heave.ugcs.caltech.edu (Postfix, from userid 3640) id 8A8508F482; Sat, 6 Jan 2007 11:14:01 -0800 (PST) Date: Sat, 6 Jan 2007 11:14:01 -0800 From: Jonathan Dama To: freebsd-arch@freebsd.org Message-ID: <20070106191401.GC8574@heave.ugcs.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: jd@ugcs.caltech.edu Cc: Ed Schouten Subject: [ed@fxq.nl: Request for PTY/devfs changes] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 19:32:24 -0000 I am forwarding this message that was posted to -current to -arch where hopefully it is unlikely to get lost in the noise. ----- Forwarded message from Ed Schouten ----- Hello everyone, A few days ago I started to toy around with FreeBSD 7.x and jails with unionfs. After a few hours I got to know the dreaded 'zombie jail' bug (PR kern/89528). I've been reading a lot of kernel source the last few days and I think I now understand a lot of existing problems in the current code. There are a couple of bugs in the FreeBSD kernel that aren't hard to cure, but will lead to a better PTY implementation: - Dev_clone event handlers cannot determine whether a LOOKUP or a CREATE is performed. When you create a small script that performs a stat() on /dev/ptyp0 to /dev/ptySv, you create a bunch of device nodes that aren't bound to a real pty controller (which leads to ucred 'leaks'). Only invoking the event handler when a CREATE is performed simplifies the entire pty design, because we could immediately construct the pty structure. The pts code also suffers from this bug. A simple stat() on /dev/ptmx causes a pts to be created. - Both the pty and pts source contain some small checks to make sure you can't open pty's from other jails. A downside of this approach is that you can see all the system's pty's in /dev. This is thus a small information leak. A nicer implementation that would even be more generic would be to add a flag to cdevsw's d_flags called D_PRISONOWNED. When this flag is set, lookup()'s and readdir()'s inside a jail don't return objects that don't have the same prison as the caller. open() should have a small check to disallow access outside the jail and when not root. PRIV_TTY_PRISON could then be renamed to PRIV_DEVFS_PRISON. When the D_PRISONOWNED flag is unset, make_dev_credv() should make sure cr_prison inside cdev's si_cred is unset to prevent prison leaks. When both changes are implemented, the pty/pts code itself could be changed to be a lot more simple. I would love to send in the patches, but I first like to hear your opinions on this subject. Are my findings correct? If not, why? -- Ed Schouten WWW: http://g-rave.nl/ ----- End forwarded message ----- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 6 20:13:30 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93E0516A407 for ; Sat, 6 Jan 2007 20:13:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 552A613C44C for ; Sat, 6 Jan 2007 20:13:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id ECD701747B; Sat, 6 Jan 2007 19:48:37 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l06JmTlP010320; Sat, 6 Jan 2007 19:48:29 GMT (envelope-from phk@critter.freebsd.dk) To: Jonathan Dama From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 06 Jan 2007 11:14:01 PST." <20070106191401.GC8574@heave.ugcs.caltech.edu> Date: Sat, 06 Jan 2007 19:48:29 +0000 Message-ID: <10319.1168112909@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Ed Schouten , freebsd-arch@freebsd.org Subject: Re: [ed@fxq.nl: Request for PTY/devfs changes] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 20:13:30 -0000 In message <20070106191401.GC8574@heave.ugcs.caltech.edu>, Jonathan Dama writes : >- Dev_clone event handlers cannot determine whether a LOOKUP or a CREATE > is performed. When you create a small script that performs a stat() on > /dev/ptyp0 to /dev/ptySv, you create a bunch of device nodes that > aren't bound to a real pty controller (which leads to ucred 'leaks'). > Only invoking the event handler when a CREATE is performed simplifies > the entire pty design, because we could immediately construct the pty > structure. The pts code also suffers from this bug. A simple stat() on > /dev/ptmx causes a pts to be created. The leak obviously is a bug. But only calling the handler on CREATE will not work, because plenty of programs will stat(2) first and find nothing there and complain to the user. It doesn't even work to send a "this if for a create" flag along for the dev_clone, because another process might race in and do something silly before we get to that level. >- Both the pty and pts source contain some small checks to make sure you > can't open pty's from other jails. A downside of this approach is that > you can see all the system's pty's in /dev. This is thus a small > information leak. A nicer implementation that would even be more > generic would be to add a flag to cdevsw's d_flags called D_PRISONOWNED. Send patch :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 6 21:58:45 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 113A316A407 for ; Sat, 6 Jan 2007 21:58:45 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by mx1.freebsd.org (Postfix) with ESMTP id B8FDF13C442 for ; Sat, 6 Jan 2007 21:58:44 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id E47311CC6E; Sat, 6 Jan 2007 22:36:51 +0100 (CET) Date: Sat, 6 Jan 2007 22:36:51 +0100 From: Ed Schouten To: Poul-Henning Kamp Message-ID: <20070106213651.GD46094@hoeg.nl> References: <20070106191401.GC8574@heave.ugcs.caltech.edu> <10319.1168112909@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FFoLq8A0u+X9iRU8" Content-Disposition: inline In-Reply-To: <10319.1168112909@critter.freebsd.dk> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-arch@freebsd.org Subject: Re: Request for PTY/devfs changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 21:58:45 -0000 --FFoLq8A0u+X9iRU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Poul-Henning Kamp wrote: > >- Dev_clone event handlers cannot determine whether a LOOKUP or a CREATE > > is performed. When you create a small script that performs a stat() on > > /dev/ptyp0 to /dev/ptySv, you create a bunch of device nodes that > > aren't bound to a real pty controller (which leads to ucred 'leaks'). > > Only invoking the event handler when a CREATE is performed simplifies > > the entire pty design, because we could immediately construct the pty > > structure. The pts code also suffers from this bug. A simple stat() on > > /dev/ptmx causes a pts to be created. >=20 > The leak obviously is a bug. >=20 > But only calling the handler on CREATE will not work, because plenty > of programs will stat(2) first and find nothing there and complain > to the user. Is it really needed that we keep such compatibility? Shouldn't those applications use grantpt(3) or pty(3) functions anyway? We could find a solution in between that still fixes stat(2), if we want to keep the compat. We could allocate a single dummy cdev in the SYSINIT that gets returned with a LOOKUP. When a CREATE is performed, we allocate a real cdev with actual contents. This causes /dev to only show devicenodes of pty's that are actually in use. We should do something like that with /dev/ptmx as well. > It doesn't even work to send a "this if for a create" flag along > for the dev_clone, because another process might race in and do > something silly before we get to that level. Sorry - I can't quite understand this. You mean a situation where two threads perform an open() on the same filename at the same time could cause two pty's to be allocated with the same name? But how is that covered at this moment when two threads perform a stat() or open() at the same time? > >- Both the pty and pts source contain some small checks to make sure you > > can't open pty's from other jails. A downside of this approach is that > > you can see all the system's pty's in /dev. This is thus a small > > information leak. A nicer implementation that would even be more > > generic would be to add a flag to cdevsw's d_flags called D_PRISONOWNE= D. >=20 > Send patch :-) I'll do :-) --=20 Ed Schouten WWW: http://g-rave.nl/ --FFoLq8A0u+X9iRU8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFoBZz52SDGA2eCwURAtuLAJ4j7UnP5nypwhdslW1TqcXZT2uAgACfWcrK E/BQcwI/xh3HUi9mX/hL3yc= =NlIm -----END PGP SIGNATURE----- --FFoLq8A0u+X9iRU8-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 6 22:10:34 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6779D16A403 for ; Sat, 6 Jan 2007 22:10:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9B213C441 for ; Sat, 6 Jan 2007 22:10:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 9A8961747B; Sat, 6 Jan 2007 22:10:32 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id l06MAQxE011098; Sat, 6 Jan 2007 22:10:26 GMT (envelope-from phk@critter.freebsd.dk) To: Ed Schouten From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 06 Jan 2007 22:36:51 +0100." <20070106213651.GD46094@hoeg.nl> Date: Sat, 06 Jan 2007 22:10:26 +0000 Message-ID: <11097.1168121426@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: Request for PTY/devfs changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2007 22:10:34 -0000 In message <20070106213651.GD46094@hoeg.nl>, Ed Schouten writes: >> But only calling the handler on CREATE will not work, because plenty >> of programs will stat(2) first and find nothing there and complain >> to the user. > >Is it really needed that we keep such compatibility? Shouldn't those >applications use grantpt(3) or pty(3) functions anyway? Not only PTY uses cloning. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.