From owner-freebsd-arch@FreeBSD.ORG Mon May 25 11:06:47 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1D8A106564A for ; Mon, 25 May 2009 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 93BDA8FC21 for ; Mon, 25 May 2009 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n4PB6lJa092710 for ; Mon, 25 May 2009 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n4PB6l2F092706 for freebsd-arch@FreeBSD.org; Mon, 25 May 2009 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 May 2009 11:06:47 GMT Message-Id: <200905251106.n4PB6l2F092706@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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, 25 May 2009 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Tue May 26 14:18:54 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6651065678; Tue, 26 May 2009 14:18:54 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id 8A81E8FC33; Tue, 26 May 2009 14:18:52 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8759C45CA6; Tue, 26 May 2009 15:55:49 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 32EB6456B1; Tue, 26 May 2009 15:55:44 +0200 (CEST) Date: Tue, 26 May 2009 15:55:47 +0200 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Message-ID: <20090526135547.GE1491@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0QFb0wBpEddLcDHQ" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: adrian@FreeBSD.org, trasz@FreeBSD.org, julian@elischer.org Subject: IP_NONLOCALOK improvements. 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, 26 May 2009 14:18:54 -0000 --0QFb0wBpEddLcDHQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Now that we have IP_NONLOCALOK IP socket option (which is something I need a lot for my company's stuff) I started to hack on it a bit. OpenBSD has SO_BINDANY SOL_SOCKET option for some time now. So first of all I wanted to do the same for FreeBSD. Unfortunately we ran out of space in so_options - it is u_short and all possible values are already taken. As a side note there is SO_NO_DDP option that is used only in cxgb driver and nowhere else. This seems like a waste of very important bit (sonner or later someone will need yet another socket option). All in all I went with rename to make at least similar to OpenBSD's option. I left it as IPPROTO_IP option: IP_BINDANY. I also implemented support for IPv6 and raw IP sockets (based on OpenBSD sources) (IPV6_BINDANY). I added new privilege - PRIV_NETINET_BINDANY, because we do have to check for privilege before allowing to use it. I removed kernel option to enable it, I see to reason not to have it in GENERIC. I also removed sysctl to enable it - we have privilege for limiting its use. The patch is here: http://people.freebsd.org/~pjd/patches/bindany.patch I tested it for AF_INET TCP, UDP and RAW (ICMP) sockets, but I'm not setup to test it for IPv6. If someone could test it for IPv6, it'd be great. SCTP also has to be tested. All you need to do after creating a socket is: int opt =3D 1; /* For IPv4. */ setsockopt(sock, IPPROTO_IP, IP_BINDANY, &opt, sizeof(opt)); /* For IPv6. */ setsockopt(sock, IPPROTO_IPV6, IPV6_BINDANY, &opt, sizeof(opt)); Then you should be able to call bind(2) with any address you want (doesn't have to be bound to any of your interfaces anymore). Once you do that you might want to send a packet to test it and observe incoming packets on connected machine. For UDP/TCP testing I've a small program, which I can provide. For RAW IP socket, I slighty modified ping (just added the above setsockopt() call), so I was able to use -S option with any address. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --0QFb0wBpEddLcDHQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKG/TiForvXbEpPzQRAuqJAKCKLolVWC/KdykoqO9z5Im7NzDlSgCgmaWK W/tZK8ldH1NdHmkgBQTxXDU= =pdhY -----END PGP SIGNATURE----- --0QFb0wBpEddLcDHQ-- From owner-freebsd-arch@FreeBSD.ORG Wed May 27 05:30:02 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DD9A1065670; Wed, 27 May 2009 05:30:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206192061.chello.pl [87.206.192.61]) by mx1.freebsd.org (Postfix) with ESMTP id BA3488FC13; Wed, 27 May 2009 05:30:01 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id C594545CDD; Wed, 27 May 2009 07:29:58 +0200 (CEST) Received: from localhost (chello087206192061.chello.pl [87.206.192.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 58D2E45CAC; Wed, 27 May 2009 07:29:53 +0200 (CEST) Date: Wed, 27 May 2009 07:29:54 +0200 From: Pawel Jakub Dawidek To: Kip Macy Message-ID: <20090527052954.GC4204@garage.freebsd.pl> References: <20090526135547.GE1491@garage.freebsd.pl> <3c1674c90905262217k7a75b73fsab25c2ef93993e18@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline In-Reply-To: <3c1674c90905262217k7a75b73fsab25c2ef93993e18@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: adrian@freebsd.org, trasz@freebsd.org, julian@elischer.org, freebsd-arch@freebsd.org Subject: Re: IP_NONLOCALOK improvements. 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: Wed, 27 May 2009 05:30:02 -0000 --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 26, 2009 at 10:17:32PM -0700, Kip Macy wrote: > On Tue, May 26, 2009 at 6:55 AM, Pawel Jakub Dawidek wr= ote: > > Now that we have IP_NONLOCALOK IP socket option (which is something I > > need a lot for my company's stuff) I started to hack on it a bit. > > > > OpenBSD has SO_BINDANY SOL_SOCKET option for some time now. So first of > > all I wanted to do the same for FreeBSD. Unfortunately we ran out of > > space in so_options - it is u_short and all possible values are already Actually so_options is short, not u_short, sorry about that. The size stays the same. > > taken. As a side note there is SO_NO_DDP option that is used only in > > cxgb driver and nowhere else. This seems like a waste of very important > > bit (sonner or later someone will need yet another socket option). >=20 > Wouldn't now (before 8.0) be a good time to expand it beyond 16 bits > rather than artificially restricting ourselves? We can do that anyway. I'd prefer not to change it to SO_BINDANY, because I'd like to MFC it and we won't be able to MFC so_options enlargement. There is also an argument that this functionality more fits as IP socket option than socket socket option. We could do something more complex, though: - Remove SO_NO_DDP from 7 (replace it with SO_BINDANY), as I don't see any users of SO_NO_DDP, at least in our tree. - Expand so_options in HEAD and add SO_NO_DDP back. But I'll left this for others to decide, as I might not be aware of the consequences of so_options type change. All I know is that there are places in the code that assume so_options is 16bit long (like tw_so_options field in tcptw structure) and xsocket structure visible in userland will also be changed. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKHM/QForvXbEpPzQRAlSOAJkBNK+YriySqoyuG94SQRPVzmA5qgCfXoSD vuEoNI+S4iXcNWC7TFyDi2E= =v97J -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- From owner-freebsd-arch@FreeBSD.ORG Wed May 27 05:45:38 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF17F106564A for ; Wed, 27 May 2009 05:45:38 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 855368FC0A for ; Wed, 27 May 2009 05:45:38 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so2433639yxb.13 for ; Tue, 26 May 2009 22:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=gD/Uq3xp0RBb7WH/yuSVh8CHIFSQQcWPAvSIcYh3i9w=; b=S7Ym27QEbG0aTchDYmBEm56ipYMxwTx5f9peAdvYsDcEedL0SOVyrB5LscTTJw/4Cs MD8S4+6bzMTnpKY617i2Bsl+EApnLm9FJINXtz7I6jX5iK8F7GQ3P9QK5NN7hAhEvFEH SCkRb1rdHtgSwki50NnFQh/caHE+QlNaonWz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=iG6cNkDwAhZIqMrcMY+w5kBxdgVydjoKPN5eS2WPfzSfIedbu80cg5CbURq1A/07ZU pf84xrcA9701eZcz7M0dmTH86gcDK0pZRCwFxUMhketfuTqUIHZ29CH36kLeF6wCtPpL pXmprfUIcB9SCngRba2xhMvRM/UXCc4WwmMQ0= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.198.3 with SMTP id v3mr10760364anf.56.1243401452808; Tue, 26 May 2009 22:17:32 -0700 (PDT) In-Reply-To: <20090526135547.GE1491@garage.freebsd.pl> References: <20090526135547.GE1491@garage.freebsd.pl> Date: Tue, 26 May 2009 22:17:32 -0700 X-Google-Sender-Auth: 3c83f5966dbec8c8 Message-ID: <3c1674c90905262217k7a75b73fsab25c2ef93993e18@mail.gmail.com> From: Kip Macy To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: adrian@freebsd.org, trasz@freebsd.org, julian@elischer.org, freebsd-arch@freebsd.org Subject: Re: IP_NONLOCALOK improvements. 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: Wed, 27 May 2009 05:45:39 -0000 On Tue, May 26, 2009 at 6:55 AM, Pawel Jakub Dawidek wrote: > Now that we have IP_NONLOCALOK IP socket option (which is something I > need a lot for my company's stuff) I started to hack on it a bit. > > OpenBSD has SO_BINDANY SOL_SOCKET option for some time now. So first of > all I wanted to do the same for FreeBSD. Unfortunately we ran out of > space in so_options - it is u_short and all possible values are already > taken. As a side note there is SO_NO_DDP option that is used only in > cxgb driver and nowhere else. This seems like a waste of very important > bit (sonner or later someone will need yet another socket option). Wouldn't now (before 8.0) be a good time to expand it beyond 16 bits rather than artificially restricting ourselves? From owner-freebsd-arch@FreeBSD.ORG Wed May 27 06:06:02 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EC2A1065686 for ; Wed, 27 May 2009 06:06:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 52B1B8FC21 for ; Wed, 27 May 2009 06:06:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B760CB9888; Tue, 26 May 2009 22:53:40 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id C97E22D6012; Tue, 26 May 2009 22:53:38 -0700 (PDT) Message-ID: <4A1CD562.9040706@elischer.org> Date: Tue, 26 May 2009 22:53:38 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20090526135547.GE1491@garage.freebsd.pl> In-Reply-To: <20090526135547.GE1491@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: adrian@FreeBSD.org, trasz@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: IP_NONLOCALOK improvements. 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: Wed, 27 May 2009 06:06:02 -0000 Pawel Jakub Dawidek wrote: > Now that we have IP_NONLOCALOK IP socket option (which is something I > need a lot for my company's stuff) I started to hack on it a bit. > > OpenBSD has SO_BINDANY SOL_SOCKET option for some time now. So first of > all I wanted to do the same for FreeBSD. Unfortunately we ran out of > space in so_options - it is u_short and all possible values are already > taken. As a side note there is SO_NO_DDP option that is used only in > cxgb driver and nowhere else. This seems like a waste of very important > bit (sonner or later someone will need yet another socket option). when I wrote the NONLOCAL stuff I was abstracting functionaity that IronPort have in their system. What they have though can not be turned off or disabled. That part was added just for the public version. I didn't know of the OpenBSd code or I might have tried to make it compatible. The test is done in the IP code so therefore it was easist to make it an IP option, though I implement it in a slightly non-IP specific manner. > > All in all I went with rename to make at least similar to OpenBSD's > option. I left it as IPPROTO_IP option: IP_BINDANY. well, ok, a rose by any other name would smell as sweet. As I said I was not aware of the OpenBSD code, but I don't like their choice of name as it doesn't really describe what it does. > > I also implemented support for IPv6 and raw IP sockets (based on OpenBSD > sources) (IPV6_BINDANY). ok, good idea. > > I added new privilege - PRIV_NETINET_BINDANY, because we do have to > check for privilege before allowing to use it. I am not sure about this. if a system has this enabled then I presume it is a special system and not a generally available time-sharing system. How do you allow a process to have this privilege? are you forcing them to be root for now? > > I removed kernel option to enable it, I see to reason not to have it in > GENERIC. Because it adds complexity and because some people do not want it even possible. You are eneabling NON-standard, (in fact "Standard-ignoring") behaviour. > > I also removed sysctl to enable it - we have privilege for limiting its use. I disagree very strongly about this one. I would liek to 1/ have to explicitly compile in thi snon standard behaviour and 2/ turn it on before we start doing this. I know how useful this is to have, (from my own experience) but feel strongly that this is pretty bad behaviour for most systems and can facilitate all sorts security worries. > > The patch is here: > > http://people.freebsd.org/~pjd/patches/bindany.patch > > I tested it for AF_INET TCP, UDP and RAW (ICMP) sockets, but I'm not > setup to test it for IPv6. If someone could test it for IPv6, it'd be > great. SCTP also has to be tested. > > All you need to do after creating a socket is: > > int opt = 1; > /* For IPv4. */ > setsockopt(sock, IPPROTO_IP, IP_BINDANY, &opt, sizeof(opt)); > /* For IPv6. */ > setsockopt(sock, IPPROTO_IPV6, IPV6_BINDANY, &opt, sizeof(opt)); > > Then you should be able to call bind(2) with any address you want > (doesn't have to be bound to any of your interfaces anymore). > > Once you do that you might want to send a packet to test it and observe > incoming packets on connected machine. > > For UDP/TCP testing I've a small program, which I can provide. For RAW > IP socket, I slighty modified ping (just added the above setsockopt() > call), so I was able to use -S option with any address. I notice that you don't say how to enable the priv. > From owner-freebsd-arch@FreeBSD.ORG Wed May 27 06:51:28 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 556A01065678; Wed, 27 May 2009 06:51:28 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206192061.chello.pl [87.206.192.61]) by mx1.freebsd.org (Postfix) with ESMTP id 94EF18FC0C; Wed, 27 May 2009 06:51:27 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 785C345CBA; Wed, 27 May 2009 08:51:25 +0200 (CEST) Received: from localhost (chello087206192061.chello.pl [87.206.192.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8B7E445CA6; Wed, 27 May 2009 08:51:19 +0200 (CEST) Date: Wed, 27 May 2009 08:51:21 +0200 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20090527065121.GD4204@garage.freebsd.pl> References: <20090526135547.GE1491@garage.freebsd.pl> <4A1CD562.9040706@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L6iaP+gRLNZHKoI4" Content-Disposition: inline In-Reply-To: <4A1CD562.9040706@elischer.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: adrian@FreeBSD.org, trasz@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: IP_NONLOCALOK improvements. 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: Wed, 27 May 2009 06:51:28 -0000 --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 26, 2009 at 10:53:38PM -0700, Julian Elischer wrote: > Pawel Jakub Dawidek wrote: > >Now that we have IP_NONLOCALOK IP socket option (which is something I > >need a lot for my company's stuff) I started to hack on it a bit. > > > >OpenBSD has SO_BINDANY SOL_SOCKET option for some time now. So first of > >all I wanted to do the same for FreeBSD. Unfortunately we ran out of > >space in so_options - it is u_short and all possible values are already > >taken. As a side note there is SO_NO_DDP option that is used only in > >cxgb driver and nowhere else. This seems like a waste of very important > >bit (sonner or later someone will need yet another socket option). >=20 >=20 > when I wrote the NONLOCAL stuff I was abstracting functionaity that > IronPort have in their system. What they have though can not be > turned off or disabled. That part was added just for the public > version. I didn't know of the OpenBSd code or I might have tried to > make it compatible. [...] I know that, Julian, and forgive me if it sounded like an accusation. I also wasn't aware that OpenBSD (and FreeBSD too) has it until yesterday:) I'm very grateful that you did the work, because now I can simplify at least three company's project. All I'm trying to do is to improve it, not to nitpick. > [...] The test is done in the IP code so therefore it=20 > was easist to make it an IP option, though I implement it in a > slightly non-IP specific manner. >=20 >=20 > > > >All in all I went with rename to make at least similar to OpenBSD's > >option. I left it as IPPROTO_IP option: IP_BINDANY. >=20 > well, ok, a rose by any other name would smell as sweet. > As I said I was not aware of the OpenBSD code, but I don't like > their choice of name as it doesn't really describe what it does. I changed the name just to be more similar to OpenBSD's (and BSD/OS') so one can more easly find it by grepping. I'm really fine with any name. > >I added new privilege - PRIV_NETINET_BINDANY, because we do have to > >check for privilege before allowing to use it. >=20 > I am not sure about this. if a system has this enabled then I presume=20 > it is a special system and not a generally available time-sharing system. >=20 > How do you allow a process to have this privilege? are you forcing=20 > them to be root for now? Our current privilege model is that we have fine-grained privileges in the kernel, but those are not _yet_ exposed to userland. All privileges defined in sys/priv.h are available for unjailed root and some (take a look at prison_priv_check() function) for jailed root. Today this new privilege will only be available for unjailed root. At some point we will grow possibility to selectively add/remove privileges just like Solaris, but we can't do that now. > >I removed kernel option to enable it, I see to reason not to have it in > >GENERIC. >=20 > Because it adds complexity and because some people do not want it even=20 > possible. > You are eneabling NON-standard, (in fact "Standard-ignoring") > behaviour. >=20 >=20 > > > >I also removed sysctl to enable it - we have privilege for limiting its= =20 > >use. >=20 > I disagree very strongly about this one. I would liek to > 1/ have to explicitly compile in thi snon standard behaviour and >=20 > 2/ turn it on >=20 > before we start doing this. >=20 >=20 > I know how useful this is to have, (from my own experience) > but feel strongly that this is pretty bad behaviour for most systems > and can facilitate all sorts security worries. Well, this is behaviour is similar to adding an IP address to an interface and binding to that address. There is even no securelevel that denies modifing interfaces, so in my opinion if one needs to explicitly ask for this to be enabled for a socket and one needs a special privilege to do it, it should be enough protection to make user's live a bit less complex by not requiring kernel recompilation and sysctl modification. I'm not sure if this was on purpose, but currently even unprivileged user can use this functionality if the sysctl is on, which I find hard to accept. Having this always enabled and requiring a privilege is IMHO more secure than allowing anyone to use it once the sysctl is on. But again, combining the two (privilege and sysctl) is redundant IMHO. If it doesn't convince you and I also don't feel convinced we need to wait for more votes:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --L6iaP+gRLNZHKoI4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKHOLoForvXbEpPzQRAr9AAJ9nT7n1W0lUvloQoMBzxHbxcnLwJQCZAV7r NXU2WYEdsLJHsYaKVT0eS5o= =vxy2 -----END PGP SIGNATURE----- --L6iaP+gRLNZHKoI4-- From owner-freebsd-arch@FreeBSD.ORG Wed May 27 15:42:28 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4C21065674; Wed, 27 May 2009 15:42:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 79E948FC1B; Wed, 27 May 2009 15:42:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EBF8846B0C; Wed, 27 May 2009 11:42:27 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 946098A028; Wed, 27 May 2009 11:42:26 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 27 May 2009 08:09:49 -0400 User-Agent: KMail/1.9.7 References: <20090526135547.GE1491@garage.freebsd.pl> <4A1CD562.9040706@elischer.org> <20090527065121.GD4204@garage.freebsd.pl> In-Reply-To: <20090527065121.GD4204@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905270809.50275.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 27 May 2009 11:42:26 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: trasz@freebsd.org, adrian@freebsd.org, Pawel Jakub Dawidek , Julian Elischer Subject: Re: IP_NONLOCALOK improvements. 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: Wed, 27 May 2009 15:42:29 -0000 On Wednesday 27 May 2009 2:51:21 am Pawel Jakub Dawidek wrote: > > I know how useful this is to have, (from my own experience) > > but feel strongly that this is pretty bad behaviour for most systems > > and can facilitate all sorts security worries. > > Well, this is behaviour is similar to adding an IP address to an > interface and binding to that address. There is even no securelevel that > denies modifing interfaces, so in my opinion if one needs to explicitly > ask for this to be enabled for a socket and one needs a special > privilege to do it, it should be enough protection to make user's live a > bit less complex by not requiring kernel recompilation and sysctl > modification. > > I'm not sure if this was on purpose, but currently even unprivileged > user can use this functionality if the sysctl is on, which I find hard > to accept. Having this always enabled and requiring a privilege is IMHO > more secure than allowing anyone to use it once the sysctl is on. > But again, combining the two (privilege and sysctl) is redundant IMHO. I think it is fine to have it in the kernel by default if it is restricted by privilege. I also agree that a root user could already accomplish this by adding an alias to the desired interface and then binding the socket (and then removing the alias if desired). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed May 27 17:03:26 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF01910656EB for ; Wed, 27 May 2009 17:03:26 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id 904FB8FC2F for ; Wed, 27 May 2009 17:03:26 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 09:51:24 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1M9MLZ-0003ob-2O for arch@freebsd.org; Wed, 27 May 2009 09:51:21 -0700 Date: Wed, 27 May 2009 09:51:20 -0700 From: Zachary Loafman To: arch@freebsd.org Message-ID: <20090527165120.GB9662@isilon.com> References: <20090511162928.GD17203@isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090511162928.GD17203@isilon.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 27 May 2009 16:51:24.0930 (UTC) FILETIME=[5F003620:01C9DEEB] Cc: Subject: Re: FAIL: kernel fault injection 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: Wed, 27 May 2009 17:03:28 -0000 On Mon, May 11, 2009 at 09:29:28AM -0700, Zachary Loafman wrote: > Arch - > > I'd like to contribute the kernel fault injection system that Isilon > uses. Before contributing it, I'd like to get approval for the APIs > involved. There were no large objections to the API. I added sleep to the man page, and I moved the tree under debug.fail_point instead of introducing a top-level. Committed as r192908: http://svn.freebsd.org/viewvc/base?view=revision&sortby=log&revision=192908 Have fun with it! -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Wed May 27 18:05:02 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8884F10656BB for ; Wed, 27 May 2009 18:05:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 68D538FC19 for ; Wed, 27 May 2009 18:05:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B1FD3D5CC3; Wed, 27 May 2009 11:05:00 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id C2D0E2D6016; Wed, 27 May 2009 11:04:58 -0700 (PDT) Message-ID: <4A1D80CA.4020702@elischer.org> Date: Wed, 27 May 2009 11:04:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20090526135547.GE1491@garage.freebsd.pl> <4A1CD562.9040706@elischer.org> <20090527065121.GD4204@garage.freebsd.pl> In-Reply-To: <20090527065121.GD4204@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: adrian@FreeBSD.org, trasz@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: IP_NONLOCALOK improvements. 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: Wed, 27 May 2009 18:05:04 -0000 Pawel Jakub Dawidek wrote: > >>> All in all I went with rename to make at least similar to OpenBSD's >>> option. I left it as IPPROTO_IP option: IP_BINDANY. >> well, ok, a rose by any other name would smell as sweet. >> As I said I was not aware of the OpenBSD code, but I don't like >> their choice of name as it doesn't really describe what it does. > > I changed the name just to be more similar to OpenBSD's (and BSD/OS') so > one can more easly find it by grepping. I'm really fine with any name. > >>> I added new privilege - PRIV_NETINET_BINDANY, because we do have to >>> check for privilege before allowing to use it. are we sure we want to make a whole PRIV just for this function? >> I am not sure about this. if a system has this enabled then I presume >> it is a special system and not a generally available time-sharing system. >> >> How do you allow a process to have this privilege? are you forcing >> them to be root for now? > > Our current privilege model is that we have fine-grained privileges in > the kernel, but those are not _yet_ exposed to userland. All privileges > defined in sys/priv.h are available for unjailed root and some (take a > look at prison_priv_check() function) for jailed root. when we have vimage, this may be required in some vimages and not others.. the priv should be inherrited but gated on the new jail.. in other words, when yo create a child jail, it can do it if: 1/ the parent can do it AND 2/ the parent allows the child to do it. > > Today this new privilege will only be available for unjailed root. > > At some point we will grow possibility to selectively add/remove > privileges just like Solaris, but we can't do that now. > >>> I removed kernel option to enable it, I see to reason not to have it in >>> GENERIC. >> Because it adds complexity and because some people do not want it even >> possible. >> You are eneabling NON-standard, (in fact "Standard-ignoring") >> behaviour. >> >> >>> I also removed sysctl to enable it - we have privilege for limiting its >>> use. >> I disagree very strongly about this one. I would liek to >> 1/ have to explicitly compile in thi snon standard behaviour and >> >> 2/ turn it on >> >> before we start doing this. >> >> >> I know how useful this is to have, (from my own experience) >> but feel strongly that this is pretty bad behaviour for most systems >> and can facilitate all sorts security worries. > > Well, this is behaviour is similar to adding an IP address to an > interface and binding to that address. There is even no securelevel that > denies modifing interfaces, so in my opinion if one needs to explicitly > ask for this to be enabled for a socket and one needs a special > privilege to do it, it should be enough protection to make user's live a > bit less complex by not requiring kernel recompilation and sysctl > modification. > > I'm not sure if this was on purpose, but currently even unprivileged > user can use this functionality if the sysctl is on, which I find hard > to accept. Having this always enabled and requiring a privilege is IMHO > more secure than allowing anyone to use it once the sysctl is on. > But again, combining the two (privilege and sysctl) is redundant IMHO. it was on purpose as it was assumed, as I said, that anyone compiling it in would be creating a special "appliance" kernel and be fully in charge of the machine. > > If it doesn't convince you and I also don't feel convinced we need to > wait for more votes:) I can live with having it there by default in GENERIC, but I'm not sure I don't still want to be able to remove it.. the sysctl could go , but I felt I wanted a way for the admin to disble it on a system if it shared a kernel with other systems that need it. i.e. if it's in GENERIC, then I think the admin should be able to stop it from being available. > From owner-freebsd-arch@FreeBSD.ORG Thu May 28 00:14:14 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ED661065670 for ; Thu, 28 May 2009 00:14:14 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id 326058FC14 for ; Thu, 28 May 2009 00:14:14 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 17:01:48 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1M9T48-0001Wn-BQ; Wed, 27 May 2009 17:01:48 -0700 Date: Wed, 27 May 2009 17:01:48 -0700 From: Zachary Loafman To: freebsd-arch@freebsd.org Message-ID: <20090528000147.GB3704@isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 28 May 2009 00:01:48.0569 (UTC) FILETIME=[7F16D090:01C9DF27] Cc: steven.danneman@isilon.com Subject: pthread_setugid_np 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, 28 May 2009 00:14:14 -0000 arch@ - Isilon has need of per-thread impersonation. We're looking at implementing something like the pthread_setugid_np mechanism found on OS X, loosely documented in the code: http://fxr.watson.org/fxr/source/bsd/kern/kern_prot.c?v=xnu-1228 (see settid and setgroups1) and some here: http://lists.apple.com/archives/perfoptimization-dev/2008/Jan/msg00043.html Does anyone have strong objections to Apple's APIs here? There's obviously no portable itnerface to handle it, and it seems a little saner to just adopt someone else's API/semantics rather than reinvent. -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Thu May 28 02:54:25 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12C89106566B for ; Thu, 28 May 2009 02:54:25 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id E75978FC28 for ; Thu, 28 May 2009 02:54:24 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 19:46:41 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1M9Vdh-0003CH-40; Wed, 27 May 2009 19:46:41 -0700 Date: Wed, 27 May 2009 19:46:41 -0700 From: Zachary Loafman To: Sujit K M Message-ID: <20090528024640.GC9388@isilon.com> References: <20090528000147.GB3704@isilon.com> <74fe56020905271931l4c8d4677h3bbcce6d8c8a8605@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74fe56020905271931l4c8d4677h3bbcce6d8c8a8605@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 28 May 2009 02:46:41.0542 (UTC) FILETIME=[87C2B260:01C9DF3E] Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 28 May 2009 02:54:25 -0000 On Thu, May 28, 2009 at 08:01:26AM +0530, Sujit K M wrote: > On Thu, May 28, 2009 at 5:31 AM, Zachary Loafman wrote: > > http://fxr.watson.org/fxr/source/bsd/kern/kern_prot.c?v=xnu-1228 > > (see settid and setgroups1) > > How about the licensing. Darwin was open source under Apple's public > license, but no longer. Or is it Mach you are taking about? I'm not proposing porting the code directly, I'm merely asking whether the API and associated semantics are acceptable. It would be fairly straightforward for us to write a unit test that could run on both FreeBSD and OS X after this exercise. -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Thu May 28 03:04:46 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DC74106566B for ; Thu, 28 May 2009 03:04:46 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: from mail-pz0-f105.google.com (mail-pz0-f105.google.com [209.85.222.105]) by mx1.freebsd.org (Postfix) with ESMTP id 113428FC13 for ; Thu, 28 May 2009 03:04:45 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: by pzk3 with SMTP id 3so748383pzk.3 for ; Wed, 27 May 2009 20:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=db9Q36IrVHhuecG/Do1sgzeaLaV6uTqlLML6jgix3Ts=; b=rtkLzasNlgjGdp4U1bZBJc+lZcDLsKpcuRbE2hJYeJXITDwfaMgB/dqQ/zyQCq9HGZ NheotC/W72vXxP1BLM2qUAQZWJkyQzWm/xgPty/m5s/rj7hpAsQk7sN+u7UfcAACF2Pm rUQ0g+YDXyBZX00O2Ucbvdp8hJQU3/c9J9wuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OfWslsLXQBRResqzZ5P4axD95wxhvM1vC1EmiktFVxDzlrmCvTK1bxsFHYWnJhASfP DDJD8nv2Knyfw4Y93iHKY1xTq/YTb9VlMnYg+Q/ttx9Bl/72DNR2YXV6VyPALPLlf4ry 1qfoDaoMY+jZ+EFzmQA4TIBN8t51rcXLFACWE= MIME-Version: 1.0 Received: by 10.110.47.17 with SMTP id u17mr18528tiu.41.1243477886449; Wed, 27 May 2009 19:31:26 -0700 (PDT) In-Reply-To: <20090528000147.GB3704@isilon.com> References: <20090528000147.GB3704@isilon.com> Date: Thu, 28 May 2009 08:01:26 +0530 Message-ID: <74fe56020905271931l4c8d4677h3bbcce6d8c8a8605@mail.gmail.com> From: Sujit K M To: Zachary Loafman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 28 May 2009 03:04:46 -0000 How about the licensing. Darwin was open source under Apple's public license, but no longer. Or is it Mach you are taking about? On Thu, May 28, 2009 at 5:31 AM, Zachary Loafman wrote: > arch@ - > > Isilon has need of per-thread impersonation. We're looking at > implementing something like the pthread_setugid_np mechanism found on > OS X, loosely documented in the code: > > http://fxr.watson.org/fxr/source/bsd/kern/kern_prot.c?v=xnu-1228 > (see settid and setgroups1) > > and some here: > http://lists.apple.com/archives/perfoptimization-dev/2008/Jan/msg00043.html > > Does anyone have strong objections to Apple's APIs here? There's > obviously no portable itnerface to handle it, and it seems a little > saner to just adopt someone else's API/semantics rather than reinvent. > > -- > Zach Loafman | Staff Engineer | Isilon Systems > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu May 28 03:39:31 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D4C106566C; Thu, 28 May 2009 03:39:31 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: from mail-pz0-f105.google.com (mail-pz0-f105.google.com [209.85.222.105]) by mx1.freebsd.org (Postfix) with ESMTP id B370E8FC17; Thu, 28 May 2009 03:39:31 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: by pzk3 with SMTP id 3so760361pzk.3 for ; Wed, 27 May 2009 20:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g7wrYXewqreofTHaXWJPSiL4TRSrmQO0qRs6PFwPDAM=; b=L6P+GsRxOzctpjn9pygT0Dm3gEviBVkst1+nKCw3p5wKhUt0w8xYi7IHt6PoIBbnBN EqnSGzSoQm7sQcu/BwjhMMtKQhGe89mUZCNWtqfIRUMOxqOXhxcIP3p738D5UZjRYrG6 3fWEHe+s4w0LBgVrMFYZ6E4U2WlkDAtY0gIFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GsQMtOFaG/LTKW1B5odVo4Z5Zb/JVIsQdeYZpGAzfTArdwu5UPkBHnL5h/FfbB4CJf FZ/cD0h/cDUBb5bW1wkS3lC1sspFpsdOPfYjPP5Q/Gjxr07/H50bXjXcu5qH0iH4+D1F YZ8WOpeuO3cHggknEokwTDNX1Y0EaMp5xwRWs= MIME-Version: 1.0 Received: by 10.110.62.4 with SMTP id k4mr21837tia.18.1243481968936; Wed, 27 May 2009 20:39:28 -0700 (PDT) In-Reply-To: <20090528024640.GC9388@isilon.com> References: <20090528000147.GB3704@isilon.com> <74fe56020905271931l4c8d4677h3bbcce6d8c8a8605@mail.gmail.com> <20090528024640.GC9388@isilon.com> Date: Thu, 28 May 2009 09:09:28 +0530 Message-ID: <74fe56020905272039h6aed0724u38dbc25d0a1be6a7@mail.gmail.com> From: Sujit K M To: Zachary Loafman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 28 May 2009 03:39:32 -0000 These are posix unix standards that you are going to be implementing. So if you are talking of only taking the interfaces, why is there any need to have objections. By the way these are a part of specification that austin group maintains at http://www.opengroup.org/certification/ On Thu, May 28, 2009 at 8:16 AM, Zachary Loafman wrote: > > On Thu, May 28, 2009 at 08:01:26AM +0530, Sujit K M wrote: >> On Thu, May 28, 2009 at 5:31 AM, Zachary Loafman wrote: >> > http://fxr.watson.org/fxr/source/bsd/kern/kern_prot.c?v=xnu-1228 >> > (see settid and setgroups1) >> >> How about the licensing. Darwin was open source under Apple's public >> license, but no longer. Or is it Mach you are taking about? > > I'm not proposing porting the code directly, I'm merely asking whether > the API and associated semantics are acceptable. It would be fairly > straightforward for us to write a unit test that could run on both > FreeBSD and OS X after this exercise. > > -- > Zach Loafman | Staff Engineer | Isilon Systems > From owner-freebsd-arch@FreeBSD.ORG Thu May 28 04:12:57 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C1FD106568C for ; Thu, 28 May 2009 04:12:57 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id DF0AF8FC1F for ; Thu, 28 May 2009 04:12:56 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 21:12:37 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1M9Wyr-0003zB-B2; Wed, 27 May 2009 21:12:37 -0700 Date: Wed, 27 May 2009 21:12:37 -0700 From: Zachary Loafman To: Sujit K M Message-ID: <20090528041236.GA14687@isilon.com> References: <20090528000147.GB3704@isilon.com> <74fe56020905271931l4c8d4677h3bbcce6d8c8a8605@mail.gmail.com> <20090528024640.GC9388@isilon.com> <74fe56020905272039h6aed0724u38dbc25d0a1be6a7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74fe56020905272039h6aed0724u38dbc25d0a1be6a7@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 28 May 2009 04:12:37.0879 (UTC) FILETIME=[892D4870:01C9DF4A] Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 28 May 2009 04:12:57 -0000 On Thu, May 28, 2009 at 09:09:28AM +0530, Sujit K M wrote: > These are posix unix standards that you are going to be implementing. > So if you are talking of only taking the interfaces, why is there any need > to have objections. pthread_setugid_np is a non-portable pthread extension for per-thread user/group impersonation on OS X. The _np on the function name is to indicate its lack of portability to other OSes - it is not part of any standard. There is no posix standard way to impersonate a user/group on a per-thread basis - and, in fact, the OS X pthread_setugid_np interface is the only one I know of in common use. I'm proposing introducing the same API and semantics to FreeBSD, thereby vaguely pushing it further towards a standard. I don't really claim it's the most elegant interface, though. -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Thu May 28 04:33:09 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78051106564A; Thu, 28 May 2009 04:33:09 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: from mail-px0-f174.google.com (mail-px0-f174.google.com [209.85.216.174]) by mx1.freebsd.org (Postfix) with ESMTP id 45E5D8FC08; Thu, 28 May 2009 04:33:09 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: by pxi4 with SMTP id 4so4339174pxi.3 for ; Wed, 27 May 2009 21:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N6A9UlmkMBQWrV/ix+l7y/afjkNm39C/6AUMBsoFD0M=; b=PAQbQqFZg7QfPrb9nUz/iQluxvZfEUV1rfeqjHerveUNLCWVmKIMTO0siolhEyTep5 wTRVlvZzOkEkV5ANcc5Xyjaw7GhNzso8jG0/s1S0g1TQnHoXaEpF2xF2VxuFQkgsFvpa zmVQnk0HAm14C9aORT4TD52f0nrMON00GQsgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O5cilG8bO2OEO2W7dhk+Dcf843ecTX2wbwoijE9LblGRfWeejwE0o9+D4b6ivahBA9 MYrTPqm7mzDYfeFGl2Gx0tHsEpNP3CMNYXnig+X0cMldRCzpzuod44+o3k/Qp2QXo72E K4/I0+o3v7M49VC8Mqn8+Vi4jc6FzYceMtEH0= MIME-Version: 1.0 Received: by 10.110.53.19 with SMTP id b19mr23387tia.34.1243485188115; Wed, 27 May 2009 21:33:08 -0700 (PDT) In-Reply-To: <20090528041236.GA14687@isilon.com> References: <20090528000147.GB3704@isilon.com> <74fe56020905271931l4c8d4677h3bbcce6d8c8a8605@mail.gmail.com> <20090528024640.GC9388@isilon.com> <74fe56020905272039h6aed0724u38dbc25d0a1be6a7@mail.gmail.com> <20090528041236.GA14687@isilon.com> Date: Thu, 28 May 2009 10:03:08 +0530 Message-ID: <74fe56020905272133r3f2ab491t962c6d0fe900e9d0@mail.gmail.com> From: Sujit K M To: Zachary Loafman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 28 May 2009 04:33:09 -0000 The Source code licensing show two license information. One the Apple license and Other the BSD License. The BSD License is to the Mach code that is present in the source code, presumably I assume. And this includes the pthread_setugid_np, but with some amount of rework with the apple OS X implementation. Are you sure that this feature was never present in any of the BSD. Or has it been moved out due to some performance requirement. As far I see if present in OS X, It is an high performance piece of code. But it need to be checked whether the code was present in earlier version of BSD. Which might make it easier for you to have it in your internal version. On Thu, May 28, 2009 at 9:42 AM, Zachary Loafman wrote: > On Thu, May 28, 2009 at 09:09:28AM +0530, Sujit K M wrote: >> These are posix unix standards that you are going to be implementing. >> So if you are talking of only taking the interfaces, why is there any need >> to have objections. > > pthread_setugid_np is a non-portable pthread extension for per-thread > user/group impersonation on OS X. The _np on the function name is to > indicate its lack of portability to other OSes - it is not part of any > standard. There is no posix standard way to impersonate a user/group on > a per-thread basis - and, in fact, the OS X pthread_setugid_np interface > is the only one I know of in common use. > > I'm proposing introducing the same API and semantics to FreeBSD, thereby > vaguely pushing it further towards a standard. I don't really claim it's > the most elegant interface, though. > > -- > Zach Loafman | Staff Engineer | Isilon Systems > > From owner-freebsd-arch@FreeBSD.ORG Thu May 28 04:48:19 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F8661065670; Thu, 28 May 2009 04:48:19 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: from mail-pz0-f105.google.com (mail-pz0-f105.google.com [209.85.222.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4918FC14; Thu, 28 May 2009 04:48:18 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: by pzk3 with SMTP id 3so786942pzk.3 for ; Wed, 27 May 2009 21:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wf+9L2LbKLtebMdLFKURaW5Wd28AE3mrwHc+zJ86lI8=; b=iO5oR1hNRdoUkXltBw7NDDZbrjDVRhZ1Tp4sNkZWSFKAy179Yu6VEYi1Sd7j6iH7Dg VFSOl+sFCI1fIz8viyhg303bIi5hpQCGpfPBARxagthHNb3vTnYlQ6Cj+ulzLZaA9UcZ 17JW1viXk/SokrgCkUURVjo9iHDVwW6NVxyro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Tn4j1SpT4seFeb+aYaOqGNRP+NrGaRRFYIY3IC2viRIrJJnp1cbg1OQ18+lNzAASa8 Frv5lN+gsC7IYzPGlRVcvX9zH5nz0v0iz+XurU9JO0KG4wwmxr+Afr/hgXyQep58mcqk GdPEmqXq6/V82VJHwsr+MgcwSdQuJTY7Ws5ro= MIME-Version: 1.0 Received: by 10.110.63.17 with SMTP id l17mr24266tia.36.1243486097835; Wed, 27 May 2009 21:48:17 -0700 (PDT) In-Reply-To: <74fe56020905272133r3f2ab491t962c6d0fe900e9d0@mail.gmail.com> References: <20090528000147.GB3704@isilon.com> <74fe56020905271931l4c8d4677h3bbcce6d8c8a8605@mail.gmail.com> <20090528024640.GC9388@isilon.com> <74fe56020905272039h6aed0724u38dbc25d0a1be6a7@mail.gmail.com> <20090528041236.GA14687@isilon.com> <74fe56020905272133r3f2ab491t962c6d0fe900e9d0@mail.gmail.com> Date: Thu, 28 May 2009 10:18:17 +0530 Message-ID: <74fe56020905272148q680cdc05tb572d576a4c3ff2b@mail.gmail.com> From: Sujit K M To: Zachary Loafman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 28 May 2009 04:48:19 -0000 As per the Apple Documentation: In some cases it is helpful to impersonate the user, at least as far as the permissions checking done by the BSD subsystem of the kernel. A single-threaded daemon can do this using seteuid and setegid. These set the effective user and group ID of the process as a whole. This will cause problems if your daemon is using multiple threads to handle requests from different users. In that case you can set the effective user and group ID of a thread using pthread_setugid_np. This was introduced in Mac OS X 10.4. (AT) http://developer.apple.com/technotes/tn2005/tn2083.html I think this is a part of the BSD (Mach) subsystem. From owner-freebsd-arch@FreeBSD.ORG Thu May 28 13:53:09 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BE5F1065670; Thu, 28 May 2009 13:53:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3CF8FC1F; Thu, 28 May 2009 13:53:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C618646B2C; Thu, 28 May 2009 09:53:08 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AD7738A02C; Thu, 28 May 2009 09:53:07 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 28 May 2009 08:12:52 -0400 User-Agent: KMail/1.9.7 References: <20090528000147.GB3704@isilon.com> <74fe56020905272133r3f2ab491t962c6d0fe900e9d0@mail.gmail.com> <74fe56020905272148q680cdc05tb572d576a4c3ff2b@mail.gmail.com> In-Reply-To: <74fe56020905272148q680cdc05tb572d576a4c3ff2b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905280812.52431.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 28 May 2009 09:53:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Zachary Loafman , steven.danneman@isilon.com, Sujit K M Subject: Re: pthread_setugid_np 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, 28 May 2009 13:53:09 -0000 On Thursday 28 May 2009 12:48:17 am Sujit K M wrote: > As per the Apple Documentation: > > In some cases it is helpful to impersonate the user, at least as far > as the permissions checking done by the BSD subsystem of the kernel. A > single-threaded daemon can do this using seteuid and setegid. These > set the effective user and group ID of the process as a whole. This > will cause problems if your daemon is using multiple threads to handle > requests from different users. In that case you can set the effective > user and group ID of a thread using pthread_setugid_np. This was > introduced in Mac OS X 10.4. > > (AT) http://developer.apple.com/technotes/tn2005/tn2083.html > > > I think this is a part of the BSD (Mach) subsystem. It has never been in BSD outside of OS X. BSD from UC Berkeley did not support kernel threads and you are free to check the CVS history of the various kern_prot.c files on other BSD's yourself. There is no BSD code to do this, and you could not use Darwin's code directly on FreeBSD anyway since the two OS's manage credential state differently. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu May 28 13:53:10 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A7941065673; Thu, 28 May 2009 13:53:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3678FC24; Thu, 28 May 2009 13:53:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B6CF246B09; Thu, 28 May 2009 09:53:09 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 77E0F8A028; Thu, 28 May 2009 09:53:08 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 28 May 2009 08:16:29 -0400 User-Agent: KMail/1.9.7 References: <20090528000147.GB3704@isilon.com> In-Reply-To: <20090528000147.GB3704@isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905280816.29617.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 28 May 2009 09:53:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: steven.danneman@isilon.com, Zachary Loafman Subject: Re: pthread_setugid_np 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, 28 May 2009 13:53:10 -0000 On Wednesday 27 May 2009 8:01:48 pm Zachary Loafman wrote: > arch@ - > > Isilon has need of per-thread impersonation. We're looking at > implementing something like the pthread_setugid_np mechanism found on > OS X, loosely documented in the code: > > http://fxr.watson.org/fxr/source/bsd/kern/kern_prot.c?v=xnu-1228 > (see settid and setgroups1) > > and some here: > http://lists.apple.com/archives/perfoptimization-dev/2008/Jan/msg00043.html > > Does anyone have strong objections to Apple's APIs here? There's > obviously no portable itnerface to handle it, and it seems a little > saner to just adopt someone else's API/semantics rather than reinvent. I suppose you would implement this by having a new flag in td_pflags to indicate that the thread is using a private credential and use that to disable the automatic updating of td_ucred on syscall return and then just point td_ucred at the thread-specific credential? Hmm, the XXX in Darwin's source about P_SUGID is probably meaningful for us as we still use that flag. I would defer to Robert on how that should work though. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu May 28 13:56:13 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07C0E10656D0; Thu, 28 May 2009 13:56:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF8268FC16; Thu, 28 May 2009 13:56:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7839746B2A; Thu, 28 May 2009 09:56:12 -0400 (EDT) Date: Thu, 28 May 2009 14:56:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <4A1D80CA.4020702@elischer.org> Message-ID: References: <20090526135547.GE1491@garage.freebsd.pl> <4A1CD562.9040706@elischer.org> <20090527065121.GD4204@garage.freebsd.pl> <4A1D80CA.4020702@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trasz@FreeBSD.org, adrian@FreeBSD.org, Pawel Jakub Dawidek , freebsd-arch@FreeBSD.org Subject: Re: IP_NONLOCALOK improvements. 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, 28 May 2009 13:56:13 -0000 On Wed, 27 May 2009, Julian Elischer wrote: >>>> I added new privilege - PRIV_NETINET_BINDANY, because we do have to check >>>> for privilege before allowing to use it. > > are we sure we want to make a whole PRIV just for this function? We have lots of privs, and in fact that's the point of privs: they should narrowly describe a specific privilege so that granting that privilege doesn't (generally) imply the granting of other privileges. Some privileges are necessarily more broad (for example, privilege to enable I/O port access from userspace implies all other privileges), but mostly this is not true of access control privileges such as this one. >>> I am not sure about this. if a system has this enabled then I presume it >>> is a special system and not a generally available time-sharing system. >>> >>> How do you allow a process to have this privilege? are you forcing them to >>> be root for now? >> >> Our current privilege model is that we have fine-grained privileges in the >> kernel, but those are not _yet_ exposed to userland. All privileges defined >> in sys/priv.h are available for unjailed root and some (take a look at >> prison_priv_check() function) for jailed root. > > when we have vimage, this may be required in some vimages and not others.. > the priv should be inherrited but gated on the new jail.. in other words, > when yo create a child jail, it can do it if: 1/ the parent can do it AND 2/ > the parent allows the child to do it. The eventual intent is to support privilege masks in FreeBSD, which would include a jail cap on privileges granted in the jail, as well as the ability to assign more specific privilege sets to specific non-root processes. I had hoped to get this done for FreeBSD 8.0, but due to other obligations, that hasn't happened. Perhaps if it goes well, we'll get one for 8.1 or 8.2. The main priority in doing this is doing it safely, since there are lots of worked examples in how not to get it right. Robert N M Watson Computer Laboratory University of Cambridge > >> >> Today this new privilege will only be available for unjailed root. >> >> At some point we will grow possibility to selectively add/remove >> privileges just like Solaris, but we can't do that now. >> >>>> I removed kernel option to enable it, I see to reason not to have it in >>>> GENERIC. >>> Because it adds complexity and because some people do not want it even >>> possible. >>> You are eneabling NON-standard, (in fact "Standard-ignoring") >>> behaviour. >>> >>> >>>> I also removed sysctl to enable it - we have privilege for limiting its >>>> use. >>> I disagree very strongly about this one. I would liek to >>> 1/ have to explicitly compile in thi snon standard behaviour and >>> >>> 2/ turn it on >>> >>> before we start doing this. >>> >>> >>> I know how useful this is to have, (from my own experience) >>> but feel strongly that this is pretty bad behaviour for most systems >>> and can facilitate all sorts security worries. >> >> Well, this is behaviour is similar to adding an IP address to an >> interface and binding to that address. There is even no securelevel that >> denies modifing interfaces, so in my opinion if one needs to explicitly >> ask for this to be enabled for a socket and one needs a special >> privilege to do it, it should be enough protection to make user's live a >> bit less complex by not requiring kernel recompilation and sysctl >> modification. >> >> I'm not sure if this was on purpose, but currently even unprivileged >> user can use this functionality if the sysctl is on, which I find hard >> to accept. Having this always enabled and requiring a privilege is IMHO >> more secure than allowing anyone to use it once the sysctl is on. >> But again, combining the two (privilege and sysctl) is redundant IMHO. > > it was on purpose as it was assumed, as I said, that anyone compiling > it in would be creating a special "appliance" kernel and be fully > in charge of the machine. > >> >> If it doesn't convince you and I also don't feel convinced we need to >> wait for more votes:) > > I can live with having it there by default in GENERIC, but I'm > not sure I don't still want to be able to remove it.. > the sysctl could go , but I felt I wanted a way for the admin > to disble it on a system if it shared a kernel with other > systems that need it. > > > i.e. if it's in GENERIC, then I think the admin should be able to stop it > from being available. > > > >> > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu May 28 15:18:17 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A1F106568A for ; Thu, 28 May 2009 15:18:17 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8E18FC1A for ; Thu, 28 May 2009 15:18:17 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 May 2009 08:18:03 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1M9hMn-0001hc-Sk; Thu, 28 May 2009 08:18:01 -0700 Date: Thu, 28 May 2009 08:18:01 -0700 From: Zachary Loafman To: John Baldwin Message-ID: <20090528151800.GA18467@isilon.com> References: <20090528000147.GB3704@isilon.com> <200905280816.29617.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905280816.29617.jhb@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 28 May 2009 15:18:03.0365 (UTC) FILETIME=[7E9EF950:01C9DFA7] Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 28 May 2009 15:18:18 -0000 On Thu, May 28, 2009 at 08:16:29AM -0400, John Baldwin wrote: > I suppose you would implement this by having a new flag in td_pflags to > indicate that the thread is using a private credential and use that to > disable the automatic updating of td_ucred on syscall return and then just > point td_ucred at the thread-specific credential? That sounds about right, though is actually more detailed than I had gotten in my cursory investigation. > Hmm, the XXX in Darwin's source about P_SUGID is probably meaningful for us as > we still use that flag. I would defer to Robert on how that should work > though. Hm, given the intent of issetugid(2), it seems like P_SUGID should instead become a count of tainted threads rather than a flag. -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Fri May 29 08:48:34 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3AB91065678; Fri, 29 May 2009 08:48:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A37138FC1F; Fri, 29 May 2009 08:48:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 41B9546B06; Fri, 29 May 2009 04:48:34 -0400 (EDT) Date: Fri, 29 May 2009 09:48:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Zachary Loafman In-Reply-To: <20090528000147.GB3704@isilon.com> Message-ID: References: <20090528000147.GB3704@isilon.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 29 May 2009 08:48:35 -0000 On Wed, 27 May 2009, Zachary Loafman wrote: > Isilon has need of per-thread impersonation. We're looking at implementing > something like the pthread_setugid_np mechanism found on OS X, loosely > documented in the code: > > http://fxr.watson.org/fxr/source/bsd/kern/kern_prot.c?v=xnu-1228 (see settid > and setgroups1) > > and some here: > http://lists.apple.com/archives/perfoptimization-dev/2008/Jan/msg00043.html > > Does anyone have strong objections to Apple's APIs here? There's obviously > no portable itnerface to handle it, and it seems a little saner to just > adopt someone else's API/semantics rather than reinvent. I'm not opposed to adding APIs along these lines, as long as it is done Very Carefully(tm). Some experience here suggests these sorts of things are very easy to do wrong, anyway. :-) Having spent some time investigating and using the APIs on Mac OS X in the last year, I can report that their usage is at times inconsistent. Applications frequently fail to properly update their full thread credentials, assuming that updating only the euid or egid is sufficient, perhaps neglecting other IDs or additional groups. While this is definitely an application bug, it is also relevant to the base OS because we do provide a set of credential-management library functions (especially setlogincontext(3)) that will not be aware of thread credentials. Per-thread credentials also require semantics that effectively preclude M:N threading with usersapce context switching being used in the future (or, at least, requires user threads with different credentials to use different kernel-visible threads, or the addition of explicit ucred descriptors to allow credential context to be saved and restored), which while not currently a huge concern, is worth thinking about. There are also potential concerns about other credential elements, such as MAC labels provided by policies that assume timely update of the label across all threads (i.e., on next entry to the kernel) as part of their semantics, and might not respond well to individual threads having other labels. This might be addressed by MAC policies having the opportunity to force an update to the per-thread credential even when running in per-thread mode in order to propagate their own changes, but we'd have to think a bit about the specific requirements. Finally: one of the things Apple found with lots of use of daemons that either switched credentials a lot in order to impersonate many users out of a singlle process, is that they ended up with a lot more different credentials in use at a time, as the fleeting credentials get referenced for the long-term by file descriptors opened when the credential was active. Our reference counting model is intended to save memory in the case where lots of credentials are the same but changes are infrequent, and so you can see kernel memory use balloon. The per-thread case is a bit better behaved than the simple per-process case frequently switching, but it's worth watching out for this. Apple addressed the problem by doing a coalesce stage after creating and initializing a new credential, in which potential existing credentials with identical contents are searched for and then used instead, discarding the new one, which comes with some overhead. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Fri May 29 09:17:11 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE5E61065672; Fri, 29 May 2009 09:17:11 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id EBA5C8FC19; Fri, 29 May 2009 09:17:08 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from outgoing.leidinger.net (pD9E2EF66.dip.t-dialin.net [217.226.239.102]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 96C5684453C; Fri, 29 May 2009 11:00:48 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 6E1A42989DD; Fri, 29 May 2009 11:00:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1243587645; bh=ZdHGVSgh5qtjEsjQsD93+S58yNB8VS8oegJyYHZqyYs=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XoQTcxzkHPBEsACYNz12326jCDHsEjh3zz4HwkBxT6zNLCsho3d3nU0Vjj99lSoSo VPHwekttPaX1NXV4IaIhuC0B1tfQe0h2nEmu7VfVCo9pJPgUvS1RVrD/tdHPUow5YC Sy2edIJ7RTWLlmykrS5jkcxfpetkj+RefDld2anzqAVRugeZwtFJZVpOfYkxUZe0A8 3iN2jquzho+LUXBPjiPsBh3Xf4ZmxP+SnDpiMUxtghk/yksLSEZmssL+Yd1dARy+GT Qt8TS3K1dxmudxeToN+/WNYy8sZ+nprL1vgcxJujCqpTNWKtGdJTpPGNRWJWD4qXhz RqQCgx55cARmw== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n4T90j8e017252; Fri, 29 May 2009 11:00:45 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 29 May 2009 11:00:44 +0200 Message-ID: <20090529110044.200461pczbdmklk4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 29 May 2009 11:00:44 +0200 From: Alexander Leidinger To: Nathan Lay References: <4A1F12E4.1060404@comcast.net> In-Reply-To: <4A1F12E4.1060404@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-8.0 Cc: arch@freebsd.org, freebsd-current@freebsd.org Subject: Re: Profile rc idea 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, 29 May 2009 09:17:13 -0000 Quoting Nathan Lay (from Thu, 28 May 2009 18:40:36 -0400): > Hi list, > Wasn't sure which list this idea belongs, so I sent it here. It arch@ (cced) is the generic place to discuss architectural changes of subsystems. > would be interesting if rc was extended to support profiles. Each > profile would reflect a different system configuration. For example > profiles could describe the computing environment at: home, work, > friend's house, airplane, etc... The active profile the system uses > could be chosen based on some contingency condition. For example, > simply prompting the user to choose an rc profile at boot, or using > hardware to choose the profile (e.g. like location based contingency > using GPS hardware), or whatever... I guess this only pertains to > booting though, but rc seems like a natural place to do this. > Thoughts, comments? Yet another idea I have no time to try... You can already do this in rc.conf: ---snip--- location=at_home case ${location} in at_home) ifconfig_xx0="..." ... ;; at_work) ifconfig_xx0="..." ... ;; *) echo wrong location set exit 1 # alternatively use some kind of default setup ;; esac ---snip--- This way you need to know before where you are, or boot into single-user mode. You can also extend it to read a kenv ("location=$(/bin/kenv profile.location)"), this way you can specify the location in the loader (bonus points to implement a loader extension in forth to read a file which lists possible profiles and offer them in the menu). Bye, Alexander. -- "I keep seeing spots in front of my eyes." "Did you ever see a doctor?" "No, just spots." http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Fri May 29 22:54:47 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5D40106564A for ; Fri, 29 May 2009 22:54:47 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id B61EF8FC17 for ; Fri, 29 May 2009 22:54:47 +0000 (UTC) (envelope-from zml@FreeBSD.org) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 May 2009 15:54:35 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1MAAy9-0001tt-UU; Fri, 29 May 2009 15:54:33 -0700 Date: Fri, 29 May 2009 15:54:33 -0700 From: Zachary Loafman To: Robert Watson Message-ID: <20090529225432.GC27779@isilon.com> References: <20090528000147.GB3704@isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 29 May 2009 22:54:35.0495 (UTC) FILETIME=[70040F70:01C9E0B0] Cc: steven.danneman@isilon.com, freebsd-arch@freebsd.org Subject: Re: pthread_setugid_np 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, 29 May 2009 22:54:48 -0000 First off, let me just say that I really appreciate such a thorough response. It was a pleasure to read. :) On Fri, May 29, 2009 at 09:48:33AM +0100, Robert Watson wrote: [...] > Having spent some time investigating and using the APIs on Mac OS X in > the last year, I can report that their usage is at times inconsistent. [...] This is one of the things I don't really like about the standard APIs, either. If I were to deviate from the Mac OS X API, I would propose something more along the lines of two calls: int pthread_setcred_np(uid_t uid, int ngroups, const git_t *gidset); void pthread_clearcred_np(); .. where clearcred is used to change the thread back to per-process credentials. I don't really like using an artifical ID for clearing it. Setting the uid and groups in the same call would provide a clue to the application writer that the supplemental group list should be considered as well. Combining the setuid and setgroups into one call also has internal advantages in that no intermediate cred is ever created. As it is, the OS X APIs are a little kludgy around setgroups. Unless I'm misunderstanding something, you can't really tell if setgroups() is modifying the per-process or per-thread credentials unless you also know whether the thread is running with per-thread credentials. > Per-thread credentials also require semantics that effectively preclude > M:N threading with usersapce context switching being used in the future I hadn't really thought much about that, because I thought M:N was effectively dead. :) > There are also potential concerns about other credential elements, such > as MAC labels provided by policies that assume timely update of the label I'm going to have to research this point a little more thoroughly, I haven't looked at the MAC interaction here. > but it's worth watching out for this. Apple addressed the problem by > doing a coalesce stage after creating and initializing a new credential, > in which potential existing credentials with identical contents are > searched for and then used instead, discarding the new one, which comes > with some overhead. This is somewhat of a concern for us, yes. In theory, the number of unique creds for us is roughly bounded by the number of active connections. However, in a multithreaded server that swaps to per-thread credentials to do Real Work, the number of creds in a naive system would end up more on the order of the number of open files. I'm not sure that's a huge concern for us, though. In theory, we might also be able to de-dupe in the background. Serialization is a concern, but it seems doable. That wouldn't incur the active overhead of keeping a cred cache. Longer term, we may be interested in working on a cred cache, too. We have other motives behind this, though: we're looking at storing alternate identities in the cred, and given the expensiveness of mapping in certain circumstances it makes a lot more sense to just hunt for an existing cred that matches. -- Zach Loafman | Staff Engineer | Isilon Systems