From jb25718@sac.sfbay.sun.com Wed Jun 17 16:13:51 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5HNDorf029136 for ; Wed, 17 Jun 2009 16:13:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5HNDlWS006134; Thu, 18 Jun 2009 00:13:49 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLE00403OJ0IJ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jun 2009 16:13:48 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLE001GOOIZLO50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 17 Jun 2009 16:13:47 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5HNDlvf031526; Wed, 17 Jun 2009 16:13:47 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5HNDkL9028526; Wed, 17 Jun 2009 16:13:46 -0700 (PDT) Received: (from jb25718@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n5HNDk2L028518; Wed, 17 Jun 2009 16:13:46 -0700 (PDT) Date: Wed, 17 Jun 2009 16:13:46 -0700 (PDT) From: Jordan Brown Subject: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] To: psarc-ext@sun.com Cc: cifs-team@sun.com Message-id: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5125 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: CIFS client updates for auto-reconnect 1.2. Name of Document Author/Supplier: Author: Gordon Ross 1.3 Date of This Document: 17 June, 2009 4. Technical Description 1. Technical Description CIFS client updates for auto-reconnect. 2. Details 2.1 Background and motivation The Solaris CIFS Client [PSARC 2005/695] provides the ability to mount SMB shares from Windows-compatible servers on Solaris. Server Message Block (SMB) is the preferred name of the protocol used for Windows-compatible file sharing. The rest of this text uses SMB in place of CIFS. As currently implemented, the SMB client performs connection setup in the context of user commands (smbutil or mount_smbfs) that first asks for a connection, and keeps that connection in the SMB client kernel module (nsmb). There is nothing in place to arrange for automatic reconnection if and when the server drops that connection. See [CR 6587713]. 2.2 New or changed features This case proposes to add a new helper program to initiate reconnection when needed, installed as: /usr/lib/smbfs/smbiod (IOD is short for I/O Deamon, a name that comes from the original BSD/Darwin code used in the SMB client.) An smbiod process is started by one of the SMB client user commands (smbutil or mount_smbfs), and continues to run until that user no longer has any SMB client connections. There will be one smbiod process for each user that has SMB client connections. [Note 1] Each smbiod processes instantiates a door service on the file "/tmp/.smbiod-%d" where %d is the owning Unix user ID, or the file "/var/run/smbiod-0" when the owner is UID zero. The door file name is first unlinked, and then created with mode 600 to prevent use by other users. The create is done via open with the O_CREAT|O_EXCL flags to prevent unintentionally opening something unexpected (i.e. symlink attacks). If the unlink or create fails, smbiod exits with an error. Once running, smbiod accepts door calls asking it to make new connections. Such door calls provide the server IP address and authentication information needed for initiating or re-creating a connection to a server. Once the connection to the server is up, smbiod calls the "nsmb" driver via ioctl, becoming the IOD service thread for that connection. If and when a connection is dropped, the driver waits for other threads to request use of the connection, returns to the user-level smbiod to re-create the connection, and enters the driver again. If a reconnection attempt fails for a temporary reason, the thread sleeps for 5 seconds before allowing requests to trigger another attempt. If a reconnection attempt fails for some permanent reason (i.e. authentication info. no longer valid) the IOD thread exits, and attempts to use that connection will get the ENOTCONN error. Such connections can be revived by running smbutil (or mount_smbfs) with new authentication information. When a connection in driver loses all its references, the IOD thread returns to smbiod and destroys the connection. When smbiod drops its last connection, it waits 15 seconds, and if no new connections are requested during that time, it deletes the door and exits. The new smbiod program is part of the SUNWsmbfsu package, along with all the other SMB client binaries. No direct user interface is provided by smbiod. 3. Interface table (no change) 4. Documentation New manual page smbiod(1M) describing what "smbiod" is and does, based on the above text. Probably similar to nfsmapid(1M). 5. References http://sac.sfbay/PSARC/2005/695/ http://docs.sun.com/app/docs/doc/819-2240/mount-smbfs-1m http://bugs.opensolaris.org/view_bug.do?bug_id=6584198 (SMB Client needs authentication improvements) http://bugs.opensolaris.org/view_bug.do?bug_id=6587713 (Need to reconnect after server disconnect) 6. Resources and Schedule n/a Appendix, Notes Note 1: Initial reviewers expected that the smbiod process might run as part of an SMF service like svc:/network/smb/client. That would be a useful improvement, but there are a few things presently used by the SMB client connection setup code that assume the calling thread's UID is that of the user for which actions are being performed. If connection setup were to be consolidated into one process, we would first need to change the supporting components to accept a UID (or credentials) argument to indicate which user this connection belongs to. It would be unfortunate to delay this important reconnection feature for such an improvement. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Jordan.Brown@sun.com Wed Jun 17 16:35:02 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5HNZ1aH010087 for ; Wed, 17 Jun 2009 16:35:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5HNYwlK004523; Thu, 18 Jun 2009 07:35:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLE00C15PIB0V00@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jun 2009 16:34:59 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLE003EHPI9HM60@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Jun 2009 16:34:57 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5HNYvbx009336; Wed, 17 Jun 2009 16:34:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLE00900PHC7A00@fe-sfbay-10.sun.com>; Wed, 17 Jun 2009 16:34:57 -0700 (PDT) Received: from [129.145.155.47] ([unknown] [129.145.155.47]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLE00H0OPI8SO40@fe-sfbay-10.sun.com>; Wed, 17 Jun 2009 16:34:57 -0700 (PDT) Date: Wed, 17 Jun 2009 16:34:56 -0700 From: Jordan Brown Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> Sender: Jordan.Brown@sun.com To: Jordan Brown Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <4A397DA0.1050208@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 239 I should perhaps note that although this case introduces no new interfaces, I thought the fact that it introduces new background processes with interesting start/stop/retry semantics made it worthy of some review from a "system" level. From carlsonj@phorcys.east.sun.com Wed Jun 17 16:44:54 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5HNir7N010664 for ; Wed, 17 Jun 2009 16:44:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5HNinTt009082; Thu, 18 Jun 2009 07:44:52 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLE00F03PYQOQ00@brm-avmta-1.central.sun.com>; Wed, 17 Jun 2009 17:44:50 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLE003EMPYPY2A0@brm-avmta-1.central.sun.com>; Wed, 17 Jun 2009 17:44:49 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5HNimR9014603; Wed, 17 Jun 2009 19:44:48 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5HNhTLG002086; Wed, 17 Jun 2009 19:43:29 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n5HNhTDX002083; Wed, 17 Jun 2009 19:43:29 -0400 (EDT) Date: Wed, 17 Jun 2009 19:43:29 -0400 From: James Carlson Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> To: Jordan Brown Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <19001.32673.775856.248844@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> Status: RO Content-Length: 615 Jordan Brown writes: > Once running, smbiod accepts door calls asking it to make new > connections. Such door calls provide the server IP address > and authentication information needed for initiating or > re-creating a connection to a server. Once the connection to What authorization or credentials are required for smbiod to accept a door call? Does it just test UID? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ro@techfak.uni-bielefeld.de Thu Jun 18 02:36:47 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5I9aivH022971 for ; Thu, 18 Jun 2009 02:36:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5I9aip1006821 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 18 Jun 2009 02:36:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLF00L0HHD83100@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 18 Jun 2009 02:36:44 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLF00G2MHD753C0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 18 Jun 2009 02:36:43 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5I9Y6bI025267 for ; Thu, 18 Jun 2009 09:36:42 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-114281; Thu, 18 Jun 2009 09:36:37 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-38482339; Thu, 18 Jun 2009 09:36:37 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-9337433; Thu, 18 Jun 2009 09:36:37 +0000 (Z) Received: from manam.TechFak.Uni-Bielefeld.DE (manam.TechFak.Uni-Bielefeld.DE [129.70.137.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id A1F0348225; Thu, 18 Jun 2009 11:36:36 +0200 (CEST) Date: Thu, 18 Jun 2009 11:36:36 +0200 From: Rainer Orth Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: Jordan Brown's message of "Wed, 17 Jun 2009 16:13:46 -0700 (PDT)" Sender: ro@techfak.uni-bielefeld.de To: Jordan Brown Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: MIME-version: 1.0 X-Mailer: Gnus v5.6.44/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.148sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 17 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> Status: RO Content-Length: 596 Jordan Brown writes: > 2.2 New or changed features > > This case proposes to add a new helper program to initiate > reconnection when needed, installed as: /usr/lib/smbfs/smbiod > (IOD is short for I/O Deamon, a name that comes from the > original BSD/Darwin code used in the SMB client.) Shouldn't the daemon reside in the existing /usr/lib/fs/smbfs directory instead of the new /usr/lib/smbfs? Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From Darren.Reed@sun.com Thu Jun 18 04:40:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5IBeFte024540 for ; Thu, 18 Jun 2009 04:40:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5IBeCuP011605; Thu, 18 Jun 2009 05:40:14 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLF00F2PN328W00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Jun 2009 04:40:14 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLF00316N30SQE0@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Jun 2009 04:40:13 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5IBeCEp006910; Thu, 18 Jun 2009 11:40:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLF00E00MGBG200@fe-emea-09.sun.com>; Thu, 18 Jun 2009 12:40:12 +0100 (BST) Received: from [129.157.18.162] ([unknown] [129.157.18.162]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLF00FN5N2YFGC0@fe-emea-09.sun.com>; Thu, 18 Jun 2009 12:40:11 +0100 (BST) Date: Thu, 18 Jun 2009 13:39:40 +0200 From: Darren Reed Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: Jordan Brown Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <4A3A277C.201@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 1510 Jordan Brown wrote: > ... > 2.2 New or changed features > > This case proposes to add a new helper program to initiate > reconnection when needed, installed as: /usr/lib/smbfs/smbiod > (IOD is short for I/O Deamon, a name that comes from the > original BSD/Darwin code used in the SMB client.) > > An smbiod process is started by one of the SMB client user > commands (smbutil or mount_smbfs), and continues to run until > that user no longer has any SMB client connections. There > will be one smbiod process for each user that has SMB client > connections. [Note 1] > > Each smbiod processes instantiates a door service on the file > "/tmp/.smbiod-%d" where %d is the owning Unix user ID, or the > file "/var/run/smbiod-0" when the owner is UID zero. The door > file name is first unlinked, and then created with mode 600 to > prevent use by other users. The create is done via open with > the O_CREAT|O_EXCL flags to prevent unintentionally opening > something unexpected (i.e. symlink attacks). If the unlink > or create fails, smbiod exits with an error. > > ... > The new smbiod program is part of the SUNWsmbfsu package, > along with all the other SMB client binaries. > > No direct user interface is provided by smbiod. > > 3. Interface table > (no change) It would seem that your interface table doesn't quite agree with 2.2, presentation of the new features, even as private, would be appreciated. Darren From carlsonj@phorcys.east.sun.com Thu Jun 18 04:54:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5IBsLkd024880 for ; Thu, 18 Jun 2009 04:54:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5IBs7qp011339; Thu, 18 Jun 2009 12:54:20 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLF00G09NQI5I00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Jun 2009 04:54:18 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLF00FFGNQHLA00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Jun 2009 04:54:18 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5IBsDD1056910; Thu, 18 Jun 2009 07:54:13 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5IBqsBb003011; Thu, 18 Jun 2009 07:52:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n5IBqsAE003008; Thu, 18 Jun 2009 07:52:54 -0400 (EDT) Date: Thu, 18 Jun 2009 07:52:54 -0400 From: James Carlson Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: To: Rainer Orth Cc: Jordan Brown , psarc-ext@sun.com, cifs-team@sun.com Message-id: <19002.10902.459280.557302@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> Status: RO Content-Length: 1005 Rainer Orth writes: > Jordan Brown writes: > > > 2.2 New or changed features > > > > This case proposes to add a new helper program to initiate > > reconnection when needed, installed as: /usr/lib/smbfs/smbiod > > (IOD is short for I/O Deamon, a name that comes from the > > original BSD/Darwin code used in the SMB client.) > > Shouldn't the daemon reside in the existing /usr/lib/fs/smbfs directory > instead of the new /usr/lib/smbfs? Fair point. When I'd originally reviewed this case, the new directory made sense because the new daemon is not a *fs plugin module. But looking at the things that are already stored under (for example) /usr/lib/fs/ufs, it's pretty clear that we haven't been sticking to that model anyway. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Gordon.Ross@sun.com Thu Jun 18 10:37:55 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5IHbtFY004560 for ; Thu, 18 Jun 2009 10:37:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5IHboS7024270; Thu, 18 Jun 2009 10:37:53 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLG00C0H3N4Q200@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Jun 2009 10:37:52 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLG004XT3N3XOC0@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Jun 2009 10:37:52 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5IHbpOZ018739; Thu, 18 Jun 2009 17:37:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLG00K002QMLM00@mail-amer.sun.com>; Thu, 18 Jun 2009 11:37:51 -0600 (MDT) Received: from [129.148.169.148] ([unknown] [129.148.169.148]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLG00GMV3N2F450@mail-amer.sun.com>; Thu, 18 Jun 2009 11:37:50 -0600 (MDT) Date: Thu, 18 Jun 2009 13:37:50 -0400 From: Gordon Ross Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <19001.32673.775856.248844@gargle.gargle.HOWL> Sender: Gordon.Ross@sun.com To: James Carlson Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <1245346670.1052.57.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> Status: RO Content-Length: 539 > Jordan Brown writes: > > Once running, smbiod accepts door calls asking it to make new > > connections. Such door calls provide the server IP address > > and authentication information needed for initiating or > > re-creating a connection to a server. Once the connection to > > What authorization or credentials are required for smbiod to accept a > door call? Does it just test UID? The door is owned by the user and has mode 0600. That appears to be sufficient to prevent other users from opening these doors. From Gordon.Ross@Sun.COM Thu Jun 18 10:40:43 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5IHeguR004637 for ; Thu, 18 Jun 2009 10:40:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5IHefHD029872; Thu, 18 Jun 2009 18:40:42 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLG00C0N3RTVW00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Jun 2009 10:40:41 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLG004HH3RRXIC0@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Jun 2009 10:40:40 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5IHedC3020459; Thu, 18 Jun 2009 17:40:39 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLG006002CZ5R00@mail-amer.sun.com>; Thu, 18 Jun 2009 11:40:39 -0600 (MDT) Received: from [129.148.169.148] ([unknown] [129.148.169.148]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLG00AWK3RQWZE0@mail-amer.sun.com>; Thu, 18 Jun 2009 11:40:38 -0600 (MDT) Date: Thu, 18 Jun 2009 13:40:38 -0400 From: Gordon Ross Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: Sender: Gordon.Ross@Sun.COM To: Rainer Orth Cc: psarc-ext@Sun.COM, cifs-team@Sun.COM Message-id: <1245346838.1052.63.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> Status: RO Content-Length: 627 > > This case proposes to add a new helper program to initiate > > reconnection when needed, installed as: /usr/lib/smbfs/smbiod > > (IOD is short for I/O Deamon, a name that comes from the > > original BSD/Darwin code used in the SMB client.) > > Shouldn't the daemon reside in the existing /usr/lib/fs/smbfs > directory > instead of the new /usr/lib/smbfs? The existing convention appears to be that "fs type" programs such as mount, umount, go in /usr/lib/fs/$FSTYPE whereas other FS support programs to in /usr/lib/$FSTYPE, such as /usr/lib/nfs/{mountd,nfsmapid} etc. I just followed that convention. From Darren.Moffat@Sun.COM Thu Jun 18 11:19:45 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5IIJiqo008039 for ; Thu, 18 Jun 2009 11:19:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5IIJbNE025887; Thu, 18 Jun 2009 19:19:43 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLG00C0J5KR9L00@brm-avmta-1.central.sun.com>; Thu, 18 Jun 2009 12:19:39 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLG000E85KQA9D0@brm-avmta-1.central.sun.com>; Thu, 18 Jun 2009 12:19:39 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5IIJcGB002464; Thu, 18 Jun 2009 18:19:38 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLG00D005JI9I00@fe-emea-10.sun.com>; Thu, 18 Jun 2009 19:19:38 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLG00AD75KIHLC0@fe-emea-10.sun.com>; Thu, 18 Jun 2009 19:19:32 +0100 (BST) Date: Thu, 18 Jun 2009 19:19:30 +0100 From: Darren J Moffat Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <1245346670.1052.57.camel@dell6300gwr> Sender: Darren.Moffat@Sun.COM To: Gordon Ross Cc: James Carlson , psarc-ext@Sun.COM, cifs-team@Sun.COM Message-id: <4A3A8532.5050700@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> <1245346670.1052.57.camel@dell6300gwr> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 755 Gordon Ross wrote: >> Jordan Brown writes: >>> Once running, smbiod accepts door calls asking it to make new >>> connections. Such door calls provide the server IP address >>> and authentication information needed for initiating or >>> re-creating a connection to a server. Once the connection to >> What authorization or credentials are required for smbiod to accept a >> door call? Does it just test UID? > > The door is owned by the user and has mode 0600. > That appears to be sufficient to prevent other > users from opening these doors. Given it is trivial to do so the door server should also check that the calling peer is running with the same creds that it is. See door_ucred(3C) and ucred_get(3C). -- Darren J Moffat From Gordon.Ross@sun.com Thu Jun 18 11:25:20 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5IIPJAQ008353 for ; Thu, 18 Jun 2009 11:25:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5IIPFOK018728; Fri, 19 Jun 2009 02:25:18 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLG00C1H5U4VV00@brm-avmta-1.central.sun.com>; Thu, 18 Jun 2009 12:25:16 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLG000WR5U4A9D0@brm-avmta-1.central.sun.com>; Thu, 18 Jun 2009 12:25:16 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5IIPGdq014248; Thu, 18 Jun 2009 18:25:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLG00K00504JH00@mail-amer.sun.com>; Thu, 18 Jun 2009 12:25:16 -0600 (MDT) Received: from [129.148.169.148] ([unknown] [129.148.169.148]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLG001SC5TS1380@mail-amer.sun.com>; Thu, 18 Jun 2009 12:25:04 -0600 (MDT) Date: Thu, 18 Jun 2009 14:25:04 -0400 From: Gordon Ross Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A3A8532.5050700@Sun.COM> Sender: Gordon.Ross@sun.com To: Darren J Moffat Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <1245349504.1052.122.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> <1245346670.1052.57.camel@dell6300gwr> <4A3A8532.5050700@Sun.COM> Status: RO Content-Length: 365 > > The door is owned by the user and has mode 0600. > > That appears to be sufficient to prevent other > > users from opening these doors. > > Given it is trivial to do so the door server should also check that the > calling peer is running with the same creds that it is. See > door_ucred(3C) and ucred_get(3C). OK, I'm happy to add that. Thanks, Gordon From Jordan.Brown@Sun.COM Thu Jun 18 13:21:38 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5IKLcUt011708 for ; Thu, 18 Jun 2009 13:21:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5IKLbUb030460; Thu, 18 Jun 2009 14:21:37 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLG0010FB80E100@brm-avmta-1.central.sun.com>; Thu, 18 Jun 2009 14:21:36 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLG00EX2B7Z3170@brm-avmta-1.central.sun.com>; Thu, 18 Jun 2009 14:21:35 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5IKLZ58015736; Thu, 18 Jun 2009 13:21:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLG00C00ATTD600@fe-sfbay-09.sun.com>; Thu, 18 Jun 2009 13:21:35 -0700 (PDT) Received: from [129.145.155.47] ([unknown] [129.145.155.47]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLG007Q4B7W4A40@fe-sfbay-09.sun.com>; Thu, 18 Jun 2009 13:21:33 -0700 (PDT) Date: Thu, 18 Jun 2009 13:21:32 -0700 From: Jordan Brown Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A3A8532.5050700@Sun.COM> Sender: Jordan.Brown@Sun.COM To: Darren J Moffat Cc: Gordon Ross , James Carlson , psarc-ext@Sun.COM, cifs-team@Sun.COM Message-id: <4A3AA1CC.4030300@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> <1245346670.1052.57.camel@dell6300gwr> <4A3A8532.5050700@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 982 For devices, I was under the impression that it was preferable to rely on file system permissions rather than having the driver do its own access control checks. Should that precedent apply here? Darren J Moffat wrote: > Gordon Ross wrote: >>> Jordan Brown writes: >>>> Once running, smbiod accepts door calls asking it to make new >>>> connections. Such door calls provide the server IP address >>>> and authentication information needed for initiating or >>>> re-creating a connection to a server. Once the connection to >>> What authorization or credentials are required for smbiod to accept a >>> door call? Does it just test UID? >> >> The door is owned by the user and has mode 0600. >> That appears to be sufficient to prevent other >> users from opening these doors. > > Given it is trivial to do so the door server should also check that the > calling peer is running with the same creds that it is. See > door_ucred(3C) and ucred_get(3C). > > From Nicolas.Williams@Sun.COM Thu Jun 18 13:29:11 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5IKTB5N012207 for ; Thu, 18 Jun 2009 13:29:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5IKSwCG020621; Thu, 18 Jun 2009 13:29:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLG0029RBKK1300@brm-avmta-1.central.sun.com>; Thu, 18 Jun 2009 14:29:08 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLG00EV8BKI2R90@brm-avmta-1.central.sun.com>; Thu, 18 Jun 2009 14:29:06 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n5IKQY3T004385; Thu, 18 Jun 2009 15:26:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5IKQYpT004384; Thu, 18 Jun 2009 15:26:34 -0500 (CDT) Date: Thu, 18 Jun 2009 15:26:34 -0500 From: Nicolas Williams Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A3A8532.5050700@Sun.COM> To: Darren J Moffat Cc: Gordon Ross , James Carlson , psarc-ext@Sun.COM, cifs-team@Sun.COM Message-id: <20090618202634.GT1308@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> <1245346670.1052.57.camel@dell6300gwr> <4A3A8532.5050700@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 925 On Thu, Jun 18, 2009 at 07:19:30PM +0100, Darren J Moffat wrote: > Gordon Ross wrote: > >>Jordan Brown writes: > >>> Once running, smbiod accepts door calls asking it to make new > >>> connections. Such door calls provide the server IP address > >>> and authentication information needed for initiating or > >>> re-creating a connection to a server. Once the connection to > >>What authorization or credentials are required for smbiod to accept a > >>door call? Does it just test UID? > > > >The door is owned by the user and has mode 0600. > >That appears to be sufficient to prevent other > >users from opening these doors. > > Given it is trivial to do so the door server should also check that the > calling peer is running with the same creds that it is. See > door_ucred(3C) and ucred_get(3C). The "same"? Sounds a bit extreme. Typically we'd check only the euid for this sort of thing. Nico -- From Darren.Moffat@sun.com Fri Jun 19 01:56:58 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5J8uwBJ001135 for ; Fri, 19 Jun 2009 01:56:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5J8utr9023163; Fri, 19 Jun 2009 01:56:58 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLH00A19A6XD900@brm-avmta-1.central.sun.com>; Fri, 19 Jun 2009 02:56:57 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLH00EENA6UIZ80@brm-avmta-1.central.sun.com>; Fri, 19 Jun 2009 02:56:54 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5J8ur1j000618; Fri, 19 Jun 2009 08:56:53 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLH006008IAIP00@fe-emea-10.sun.com>; Fri, 19 Jun 2009 09:56:53 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLH00B6EA6S6K90@fe-emea-10.sun.com>; Fri, 19 Jun 2009 09:56:53 +0100 (BST) Date: Fri, 19 Jun 2009 09:56:52 +0100 From: Darren J Moffat Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A3AA1CC.4030300@sun.com> Sender: Darren.Moffat@sun.com To: Jordan Brown Cc: Gordon Ross , James Carlson , psarc-ext@sun.com, cifs-team@sun.com Message-id: <4A3B52D4.8090706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> <1245346670.1052.57.camel@dell6300gwr> <4A3A8532.5050700@Sun.COM> <4A3AA1CC.4030300@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1471 Jordan Brown wrote: > For devices, I was under the impression that it was preferable to rely > on file system permissions rather than having the driver do its own > access control checks. Should that precedent apply here? Depends, but this isn't a driver it is a door server. IMO door servers need to be as robust as possible - particularly if they are running with any privilege but even if they are running as a "normal" user. Not only should they check who the peer caller is but they also need to be very very careful about how they parse the input coming over the door. See the (unfortunately closed) source for kcfd as an example. > Darren J Moffat wrote: >> Gordon Ross wrote: >>>> Jordan Brown writes: >>>>> Once running, smbiod accepts door calls asking it to make new >>>>> connections. Such door calls provide the server IP address >>>>> and authentication information needed for initiating or >>>>> re-creating a connection to a server. Once the connection to >>>> What authorization or credentials are required for smbiod to accept a >>>> door call? Does it just test UID? >>> >>> The door is owned by the user and has mode 0600. >>> That appears to be sufficient to prevent other >>> users from opening these doors. >> >> Given it is trivial to do so the door server should also check that >> the calling peer is running with the same creds that it is. See >> door_ucred(3C) and ucred_get(3C). >> >> -- Darren J Moffat From ro@techfak.uni-bielefeld.de Fri Jun 19 05:17:33 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5JCHW4R003631 for ; Fri, 19 Jun 2009 05:17:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5JCHSqL010602; Fri, 19 Jun 2009 13:17:30 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLH00105JH63R00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 19 Jun 2009 05:17:30 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLH0029LJH4GBA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 19 Jun 2009 05:17:29 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5JCHAoj000219; Fri, 19 Jun 2009 12:17:28 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-390379; Fri, 19 Jun 2009 12:17:28 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-69777735; Fri, 19 Jun 2009 12:17:27 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-3592422; Fri, 19 Jun 2009 12:17:27 +0000 (Z) Received: from manam.TechFak.Uni-Bielefeld.DE (manam.TechFak.Uni-Bielefeld.DE [129.70.137.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id EC2F248283; Fri, 19 Jun 2009 14:16:56 +0200 (CEST) Date: Fri, 19 Jun 2009 14:16:55 +0200 (MEST) From: Rainer Orth Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <1245346838.1052.63.camel@dell6300gwr> To: Gordon Ross Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <19003.33207.169747.176634@manam.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.421sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <1245346838.1052.63.camel@dell6300gwr> Status: RO Content-Length: 1227 Gordon Ross writes: > > > This case proposes to add a new helper program to initiate > > > reconnection when needed, installed as: /usr/lib/smbfs/smbiod > > > (IOD is short for I/O Deamon, a name that comes from the > > > original BSD/Darwin code used in the SMB client.) > > > > Shouldn't the daemon reside in the existing /usr/lib/fs/smbfs > > directory > > instead of the new /usr/lib/smbfs? > > The existing convention appears to be that "fs type" programs > such as mount, umount, go in /usr/lib/fs/$FSTYPE whereas > other FS support programs to in /usr/lib/$FSTYPE, such as > /usr/lib/nfs/{mountd,nfsmapid} etc. > > I just followed that convention. As Jim already commented, there seems to be confusion here what the actual convention is. Apart from /usr/lib/fs/ufs, another case in point (which doesn't only contain filesystem-specific plugins, but also e.g. cachefsd), is /usr/lib/fs/cachefs. I suppose it makes more sense to collect everything in one place (/usr/lib/fs/) than to randomly scatter them over two different ones. Comments? Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From Jordan.Brown@sun.com Fri Jun 19 10:01:08 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5JH183Y011777 for ; Fri, 19 Jun 2009 10:01:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5JH14hE059905; Fri, 19 Jun 2009 11:01:07 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLH00D1ZWLUO600@nwk-avmta-1.sfbay.Sun.COM>; Fri, 19 Jun 2009 10:01:07 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLH00CD2WLUV810@nwk-avmta-1.sfbay.Sun.COM>; Fri, 19 Jun 2009 10:01:06 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5JH16rC024406; Fri, 19 Jun 2009 10:01:06 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLH00500WFIR700@fe-sfbay-09.sun.com>; Fri, 19 Jun 2009 10:01:06 -0700 (PDT) Received: from [129.145.155.47] ([unknown] [129.145.155.47]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLH00JBUWLOVAB0@fe-sfbay-09.sun.com>; Fri, 19 Jun 2009 10:01:01 -0700 (PDT) Date: Fri, 19 Jun 2009 10:01:00 -0700 From: Jordan Brown Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A3B52D4.8090706@Sun.COM> Sender: Jordan.Brown@sun.com To: Darren J Moffat Cc: Gordon Ross , James Carlson , psarc-ext@sun.com, cifs-team@sun.com Message-id: <4A3BC44C.9070602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> <1245346670.1052.57.camel@dell6300gwr> <4A3A8532.5050700@Sun.COM> <4A3AA1CC.4030300@sun.com> <4A3B52D4.8090706@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 1807 For the purposes of this case I don't care one way or the other - Darren asked for it, Gordon said OK. However, I think there are interesting philosophical questions, so I'm continuing the discussion in private. If anybody else is interested in joining in, just ask (privately). Darren J Moffat wrote: > Jordan Brown wrote: >> For devices, I was under the impression that it was preferable to rely >> on file system permissions rather than having the driver do its own >> access control checks. Should that precedent apply here? > > Depends, but this isn't a driver it is a door server. > > IMO door servers need to be as robust as possible - particularly if they > are running with any privilege but even if they are running as a > "normal" user. Not only should they check who the peer caller is but > they also need to be very very careful about how they parse the input > coming over the door. See the (unfortunately closed) source for kcfd as > an example. > >> Darren J Moffat wrote: >>> Gordon Ross wrote: >>>>> Jordan Brown writes: >>>>>> Once running, smbiod accepts door calls asking it to make new >>>>>> connections. Such door calls provide the server IP address >>>>>> and authentication information needed for initiating or >>>>>> re-creating a connection to a server. Once the connection to >>>>> What authorization or credentials are required for smbiod to accept a >>>>> door call? Does it just test UID? >>>> >>>> The door is owned by the user and has mode 0600. >>>> That appears to be sufficient to prevent other >>>> users from opening these doors. >>> >>> Given it is trivial to do so the door server should also check that >>> the calling peer is running with the same creds that it is. See >>> door_ucred(3C) and ucred_get(3C). >>> >>> > > From Darren.Moffat@sun.com Fri Jun 19 10:21:07 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5JHL6Qe012527 for ; Fri, 19 Jun 2009 10:21:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5JHKtj7018533; Sat, 20 Jun 2009 01:21:06 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLH00C0XXJ4IK00@brm-avmta-1.central.sun.com>; Fri, 19 Jun 2009 11:21:04 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLH00L3KXJ2H3A0@brm-avmta-1.central.sun.com>; Fri, 19 Jun 2009 11:21:03 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5JHL25k022086; Fri, 19 Jun 2009 17:21:02 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLH00300XELNU00@fe-emea-09.sun.com>; Fri, 19 Jun 2009 18:21:02 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLH00LAUXIUN440@fe-emea-09.sun.com>; Fri, 19 Jun 2009 18:20:55 +0100 (BST) Date: Fri, 19 Jun 2009 18:20:54 +0100 From: Darren J Moffat Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A3BC44C.9070602@sun.com> Sender: Darren.Moffat@sun.com To: Jordan Brown Cc: Gordon Ross , James Carlson , psarc-ext@sun.com, cifs-team@sun.com Message-id: <4A3BC8F6.2060508@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> <1245346670.1052.57.camel@dell6300gwr> <4A3A8532.5050700@Sun.COM> <4A3AA1CC.4030300@sun.com> <4A3B52D4.8090706@Sun.COM> <4A3BC44C.9070602@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1510 Jordan Brown wrote: > For the purposes of this case I don't care one way or the other - Darren > asked for it, Gordon said OK. However, I think there are interesting > philosophical questions, so I'm continuing the discussion in private. > If anybody else is interested in joining in, just ask (privately). > > Darren J Moffat wrote: >> Jordan Brown wrote: >>> For devices, I was under the impression that it was preferable to >>> rely on file system permissions rather than having the driver do its >>> own access control checks. Should that precedent apply here? >> >> Depends, but this isn't a driver it is a door server. >> >> IMO door servers need to be as robust as possible - particularly if >> they are running with any privilege but even if they are running as a >> "normal" user. Not only should they check who the peer caller is but >> they also need to be very very careful about how they parse the input >> coming over the door. See the (unfortunately closed) source for kcfd >> as an example. In this case given the daemon is running as a normal user (but I assume it originally started with privilege so has SNOCD set right?) the door server should check that its euid matches that of the caller, or the caller's euid == 0 and has all privs (or the kernel will use a cred_t with euid == the user's). Additional protection that we are really being called by who we expect it to be called by - which BTW isn't actually clear from the case materials. -- Darren J Moffat From Gordon.Ross@sun.com Mon Jun 22 11:09:28 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5MI9SqR024116 for ; Mon, 22 Jun 2009 11:09:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5MI9SAe056145; Mon, 22 Jun 2009 12:09:28 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLN00I05JRRPJ00@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jun 2009 11:09:27 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLN00EOGJRRS860@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Jun 2009 11:09:27 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5MI9RmN021928; Mon, 22 Jun 2009 18:09:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLN00600IY8A100@mail-amer.sun.com>; Mon, 22 Jun 2009 12:09:27 -0600 (MDT) Received: from [192.168.1.6] ([unknown] [75.67.12.95]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLN00BOYJRD2450@mail-amer.sun.com>; Mon, 22 Jun 2009 12:09:14 -0600 (MDT) Date: Mon, 22 Jun 2009 14:09:13 -0400 From: Gordon Ross Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A3BC8F6.2060508@Sun.COM> Sender: Gordon.Ross@sun.com To: Darren J Moffat Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <1245694153.1048.15.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <19001.32673.775856.248844@gargle.gargle.HOWL> <1245346670.1052.57.camel@dell6300gwr> <4A3A8532.5050700@Sun.COM> <4A3AA1CC.4030300@sun.com> <4A3B52D4.8090706@Sun.COM> <4A3BC44C.9070602@sun.com> <4A3BC8F6.2060508@Sun.COM> Status: RO Content-Length: 1457 Darren Moffat wrote: > >> IMO door servers need to be as robust as possible - particularly if > >> they are running with any privilege but even if they are running as a > >> "normal" user. Not only should they check who the peer caller is but > >> they also need to be very very careful about how they parse the input > >> coming over the door. See the (unfortunately closed) source for kcfd > >> as an example. There's not much in the way of parsing. The door server accepts just one fixed-size structure containing stuff like the server IP address, user name, NTLM hash, some flags, etc. > In this case given the daemon is running as a normal user (but I assume > it originally started with privilege so has SNOCD set right?) the door It's started by via fork/exec from a program also running as a normal user, so it should not have any extra privileges. > server should check that its euid matches that of the caller, or the > caller's euid == 0 and has all privs (or the kernel will use a cred_t > with euid == the user's). Additional protection that we are really > being called by who we expect it to be called by - which BTW isn't > actually clear from the case materials. In the case materials, I described the door permissions and ownership. While I still think that should be entirely sufficient, I don't mind adding another check if someone will point me to an example of what the check should look like. Thanks, Gordon From Gordon.Ross@sun.com Mon Jun 22 11:24:04 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5MIO4Z9025030 for ; Mon, 22 Jun 2009 11:24:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5MIO21J014840; Mon, 22 Jun 2009 11:24:04 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLN00507KG3V400@brm-avmta-1.central.sun.com>; Mon, 22 Jun 2009 12:24:03 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLN00E5RKG28RA0@brm-avmta-1.central.sun.com>; Mon, 22 Jun 2009 12:24:02 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5MIO2GG028765; Mon, 22 Jun 2009 18:24:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLN00600JZHWK00@mail-amer.sun.com>; Mon, 22 Jun 2009 12:24:02 -0600 (MDT) Received: from [192.168.1.6] ([unknown] [75.67.12.95]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLN002BBKFSOTG0@mail-amer.sun.com>; Mon, 22 Jun 2009 12:23:53 -0600 (MDT) Date: Mon, 22 Jun 2009 14:23:52 -0400 From: Gordon Ross Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A3A277C.201@Sun.COM> Sender: Gordon.Ross@sun.com To: Darren Reed Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <1245695032.1048.27.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <4A3A277C.201@Sun.COM> Status: RO Content-Length: 928 Darren Reed wrote: > > ... > > 2.2 New or changed features > > > > This case proposes to add a new helper program to initiate > > reconnection when needed, installed as: /usr/lib/smbfs/smbiod [...] > > Each smbiod processes instantiates a door service on the file > > "/tmp/.smbiod-%d" where %d is the owning Unix user ID, or the > > file "/var/run/smbiod-0" when the owner is UID zero. [...] > > > 3. Interface table > > (no change) > > It would seem that your interface table doesn't quite agree with 2.2, > presentation of the new features, even as private, would be appreciated. OK, if names in the filesystem need to be listed in the Interface table, the case should list these additions: /usr/lib/smbfs/smbiod See smbiod.1m /tmp/.smbiod-%d where %d is the user's UID /var/run/smbiod-0 when owner is UID zero Should those go in the FILES section of the man page too? Thanks, Gordon From Gordon.Ross@sun.com Tue Jun 23 08:23:38 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5NFNcZY024806 for ; Tue, 23 Jun 2009 08:23:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5NFNXuc062600; Tue, 23 Jun 2009 09:23:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLP007036RDVJ00@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jun 2009 08:23:37 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLP004OW6RCID50@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jun 2009 08:23:36 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5NFNZJr014610; Tue, 23 Jun 2009 15:23:35 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLP00C005VNA200@mail-amer.sun.com>; Tue, 23 Jun 2009 09:23:35 -0600 (MDT) Received: from [129.148.169.99] ([unknown] [129.148.169.99]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLP00IV96R9X5F0@mail-amer.sun.com>; Tue, 23 Jun 2009 09:23:34 -0600 (MDT) Date: Tue, 23 Jun 2009 11:23:33 -0400 From: Gordon Ross Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <19003.33207.169747.176634@manam.TechFak.Uni-Bielefeld.DE> Sender: Gordon.Ross@sun.com To: Rainer Orth Cc: psarc-ext@sun.com, cifs-team@sun.com Message-id: <1245770613.993.6.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <1245346838.1052.63.camel@dell6300gwr> <19003.33207.169747.176634@manam.TechFak.Uni-Bielefeld.DE> Status: RO Content-Length: 1504 > > The existing convention appears to be that "fs type" programs > > such as mount, umount, go in /usr/lib/fs/$FSTYPE whereas > > other FS support programs [go] in /usr/lib/$FSTYPE, such as > > /usr/lib/nfs/{mountd,nfsmapid} etc. > > > > I just followed that convention. > > As Jim already commented, there seems to be confusion here what the actual > convention is. Apart from /usr/lib/fs/ufs, another case in point (which > doesn't only contain filesystem-specific plugins, but also e.g. cachefsd), > is /usr/lib/fs/cachefs. > > I suppose it makes more sense to collect everything in one place > (/usr/lib/fs/) than to randomly scatter them over two different > ones. > > Comments? > > Rainer It appears that cachefs is the "odd man out" here. I'd rather follow the precedent of autofs, nfs, zfs, unless someone can point to rules to the contrary. Here are the current usr/lib/fs and usr/lib files: usr/lib/fs/autofs: automount dfshares mount share unshare usr/lib/autofs: automountd usr/lib/fs/cachefs: cachefsd cachefslog cachefspack cachefsstat cachefswssize cfsadmin cfsfstype cfstagchk dfshares fsck mount share umount unshare usr/lib/fs/nfs: amd64 dfmounts dfshares libshare_nfs.so.1 mount nfsfind showmount umount usr/lib/nfs: libmapid.so libmapid.so.1 llib-lmapid llib-lmapid.ln lockd mountd nfs4cbd nfsd nfslogd nfsmapid rquotad statd usr/lib/fs/zfs: fsimage.so fstyp fstyp.so.1 mount umount usr/lib/zfs: availdevs pyzfs.py pyzfs.pyc From carlsonj@carlson.workingcode.com Tue Jun 23 08:32:11 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5NFWB4e024860 for ; Tue, 23 Jun 2009 08:32:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5NFW6HM003504; Tue, 23 Jun 2009 09:32:10 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLP00C0775LJ900@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jun 2009 08:32:09 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLP005YI75KO190@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jun 2009 08:32:09 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5NEvsCJ008108; Tue, 23 Jun 2009 15:32:08 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay42i.sun.com with ESMTP id BT-MMP-618166; Tue, 23 Jun 2009 15:32:07 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-46505257; Tue, 23 Jun 2009 15:32:07 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-1953782; Tue, 23 Jun 2009 15:32:06 +0000 (Z) Received: from carlson.workingcode.com (localhost [127.0.0.1]) by carlson.workingcode.com (8.14.3+Sun/8.14.3) with ESMTP id n5NFW6sj007720; Tue, 23 Jun 2009 11:32:06 -0400 (EDT) Received: (from carlsonj@localhost) by carlson.workingcode.com (8.14.3+Sun/8.14.3/Submit) id n5NFW6FD007717; Tue, 23 Jun 2009 11:32:06 -0400 (EDT) Date: Tue, 23 Jun 2009 11:32:06 -0400 From: James Carlson Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: Gordon Ross's message of 23 June 2009 11:23:33 Sender: carlsonj@carlson.workingcode.com To: Gordon Ross Cc: Rainer Orth , psarc-ext@sun.com, cifs-team@sun.com Message-id: <19008.62838.183678.769751@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under Emacs 22.1.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-Misty-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.048sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <1245346838.1052.63.camel@dell6300gwr> <19003.33207.169747.176634@manam.TechFak.Uni-Bielefeld.DE> <1245770613.993.6.camel@dell6300gwr> Status: RO Content-Length: 284 Gordon Ross writes: > It appears that cachefs is the "odd man out" here. > I'd rather follow the precedent of autofs, nfs, zfs, > unless someone can point to rules to the contrary. Seems reasonable to me. -- James Carlson 42.703N 71.076W From ro@techfak.uni-bielefeld.de Tue Jun 23 09:27:15 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5NGRD5C025938 for ; Tue, 23 Jun 2009 09:27:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5NGR3Nb025775; Tue, 23 Jun 2009 09:27:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLP00B319PB9200@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jun 2009 09:27:11 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLP0047G9PAIHA0@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Jun 2009 09:27:10 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5NFcKcU022193; Tue, 23 Jun 2009 16:27:10 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay41i.sun.com with ESMTP id BT-MMP-628012; Tue, 23 Jun 2009 16:26:24 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-76110986; Tue, 23 Jun 2009 16:26:22 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-10824962; Tue, 23 Jun 2009 16:25:59 +0000 (Z) Received: from manam.TechFak.Uni-Bielefeld.DE (manam.TechFak.Uni-Bielefeld.DE [129.70.137.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 882E5481ED; Tue, 23 Jun 2009 17:58:05 +0200 (CEST) Date: Tue, 23 Jun 2009 17:58:03 +0200 (MEST) From: Rainer Orth Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <19008.62838.183678.769751@gargle.gargle.HOWL> To: James Carlson Cc: Gordon Ross , psarc-ext@sun.com, cifs-team@sun.com Message-id: <19008.64395.471602.126468@manam.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.391sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <1245346838.1052.63.camel@dell6300gwr> <19003.33207.169747.176634@manam.TechFak.Uni-Bielefeld.DE> <1245770613.993.6.camel@dell6300gwr> <19008.62838.183678.769751@gargle.gargle.HOWL> Status: RO Content-Length: 522 James Carlson writes: > Gordon Ross writes: > > It appears that cachefs is the "odd man out" here. > > I'd rather follow the precedent of autofs, nfs, zfs, > > unless someone can point to rules to the contrary. > > Seems reasonable to me. Agreed, although the rest seems not to be completely clean either. But the cachefs case will probably go away reasonably soon anyway. Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From Jordan.Brown@sun.com Tue Jun 23 10:16:02 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5NHG1oN028513 for ; Tue, 23 Jun 2009 10:16:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5NHFxZu002029 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 23 Jun 2009 18:16:01 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLP00E0XBYNNY00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 23 Jun 2009 11:15:59 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLP00DTYBYMR410@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 23 Jun 2009 11:15:59 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5NHFws1024530 for ; Tue, 23 Jun 2009 10:15:58 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLP00M00BCGU700@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 23 Jun 2009 10:15:58 -0700 (PDT) Received: from [129.145.155.47] ([unknown] [129.145.155.47]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLP002OTBYIQJH0@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 23 Jun 2009 10:15:55 -0700 (PDT) Date: Tue, 23 Jun 2009 10:15:54 -0700 From: Jordan Brown Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <1245770613.993.6.camel@dell6300gwr> Sender: Jordan.Brown@sun.com To: Gordon Ross Cc: psarc-ext@sun.com Message-id: <4A410DCA.6030101@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <1245346838.1052.63.camel@dell6300gwr> <19003.33207.169747.176634@manam.TechFak.Uni-Bielefeld.DE> <1245770613.993.6.camel@dell6300gwr> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 26 Can we have a +1, please? From gdamore@sun.com Wed Jun 24 09:32:49 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5OGWnlY004816 for ; Wed, 24 Jun 2009 09:32:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5OGWmcx028110 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 24 Jun 2009 10:32:49 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLR0022B4MOQW00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Jun 2009 10:32:48 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLR00FO34MMP780@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Jun 2009 10:32:46 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5OGWkVJ023442 for ; Wed, 24 Jun 2009 09:32:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLR00F0044TAG00@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Jun 2009 09:32:45 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLR00MZI4LRF480@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 24 Jun 2009 09:32:16 -0700 (PDT) Date: Wed, 24 Jun 2009 09:32:15 -0700 From: "Garrett D'Amore" Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A410DCA.6030101@sun.com> Sender: Garrett.Damore@sun.com To: Jordan Brown Cc: Gordon Ross , PSARC-ext@sun.com Message-id: <4A42550F.8080607@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <1245346838.1052.63.camel@dell6300gwr> <19003.33207.169747.176634@manam.TechFak.Uni-Bielefeld.DE> <1245770613.993.6.camel@dell6300gwr> <4A410DCA.6030101@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 531 Jordan Brown wrote: > Can we have a +1, please? I've read over the case materials, and I think I'm happy. The issues at hand seem to be validating the door user, and it seems to me that the approach is robust... if Darren wants to insist on further checks then he will need to so (and in any case the project team seems more than willing to comply with any such reasonable requests.) It also seems that the smbiod will live in /usr/lib/fs/smbfs/ -- if that is the case, then I'll go ahead and grant a +1. - Garrett From Jordan.Brown@sun.com Wed Jun 24 11:31:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5OIVEac013496 for ; Wed, 24 Jun 2009 11:31:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5OIVEKF033878 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 24 Jun 2009 12:31:14 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLR00H0HA409G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Jun 2009 11:31:12 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLR00AU2A40LNC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Jun 2009 11:31:12 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5OIVC8w002967 for ; Wed, 24 Jun 2009 11:31:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLR00I009KL6E00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Jun 2009 11:31:12 -0700 (PDT) Received: from [129.145.155.47] ([unknown] [129.145.155.47]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLR009PTA3ZXP70@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 24 Jun 2009 11:31:12 -0700 (PDT) Date: Wed, 24 Jun 2009 11:31:11 -0700 From: Jordan Brown Subject: Re: CIFS client updates for auto-reconnect [PSARC/2009/366 FastTrack timeout 06/24/2009] In-reply-to: <4A42550F.8080607@sun.com> Sender: Jordan.Brown@sun.com To: PSARC-ext@sun.com Message-id: <4A4270EF.3020707@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906172313.n5HNDk2L028518@sac.sfbay.sun.com> <1245346838.1052.63.camel@dell6300gwr> <19003.33207.169747.176634@manam.TechFak.Uni-Bielefeld.DE> <1245770613.993.6.camel@dell6300gwr> <4A410DCA.6030101@sun.com> <4A42550F.8080607@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 43 This case was approved at today's meeting. From Gordon.Ross@oracle.com Tue May 25 12:57:56 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4PJvuTa021029 for ; Tue, 25 May 2010 12:57:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4PJvt2N023396 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 25 May 2010 14:57:55 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Z00D01RGJQM00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 25 May 2010 12:57:55 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Z00347RGJLD80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 25 May 2010 12:57:55 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4PJvsAj015300 for ; Tue, 25 May 2010 19:57:54 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PFxkSR002430 for ; Tue, 25 May 2010 19:57:50 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 297320931274817469; Tue, 25 May 2010 12:57:49 -0700 Received: from [192.168.1.6] (/75.67.12.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 12:57:49 -0700 Date: Tue, 25 May 2010 15:57:47 -0400 From: Gordon Ross Subject: case note for PSARC/2009/366 CIFS client updates for auto-reconnect To: psarc-ext@sun.com Message-id: <1274817467.4327.82.camel@dell6300gwr> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BFC2BC2.00CB:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 2366 This is a minor update to an already approved case: PSARC/2009/366 (CIFS client updates for auto-reconnect) I am filing this as a "case note", but if anyone thinks this should have it's own case, let me know and I'll get this submitted as a new fasttrack. We propose to change the way smbiod(1M) processes are started, letting them run as an SMF service. This idea was suggested in discussions of the original case, but not implemented at that time. We'd like to do that now. The case materials as of June 2009 specify that smbiod is started by one of the SMB client user commands (smbutil or mount_smbfs). We now propose to change that so smbiod will run as an SMF service process under the (already existing) FMRI: svc:/network/smb/client. This allows other consumers of libsmbfs to request creation of a per-user smbiod without using fork/exec from that consumer, avoiding complications when the consumer is an SMF service, or running with reduced privileges, etc. The design of smbiod is changed only slightly by this new startup mechanism. We still need an smbiod process for each local user to implement separate credentials, similar to the design used by nscd(1M) for "self credentialed" name services. [ PSARC/2005/133 ] The per-user smbiod processes still come and go based on demand, minimizing system memory footprint. What changes is that the svc:/network/smb/client service now runs one "master" smbiod that handles the job of creating new per-user smbiod processes when necessary. The master smbiod instantiates a door /var/run/smbiod/.svc which can be used by ordinary user processes to request the creation of their own per-user smbiod process. When requested, the master smbiod starts up a child smbiod process with the user credentials from the client side of the master's door, and with all unnecessary privileges dropped. The "master" smbiod is implemented as a new program: /usr/lib/smbfs/smbiod-svc which will be added to the existing smbiod(1M) man page. As described previously in PSARC/2009/366, each per-user smbiod process instantiates a door for the private use of that user. One security enhancement made possible by this design change is that the per-user smbiod door can now be in a directory that's not publically writable. The new location for these per-user doors is: /var/run/smbiod/$UID (previously was in /tmp)