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) _______________________________________________ opensolaris-arc mailing list [email protected]
