Difference between revisions of "Samba4/s3fs"
|Line 5:||Line 5:|
=How it is implemented=
=How it is implemented=
the smbd file server has a distinct history from the ntvfs file server that the Samba4 development project has used so far, it did not natrually use the same security subsystems and other resources common the the rest of the AD server. Indeed, at a time before the [[Franky]] effort was started, it was not even in the same GIT tree, and certainly not the same build tree.
==The merged build==
==The merged build==
Revision as of 06:35, 27 April 2012
What is s3fs
s3fs is the name that has been given to a development effort to make possible the agreed default file server configuration for Samba 4.0
It was agreed at SambaXP 2010 that Samba 4.0 would release with the smbd file server in use by default, so that users upgrading from Samba 3.x DC environments would still have access to all the features of those environment that they had come to expect.
How it is implemented
Because the smbd file server has a distinct history from the ntvfs file server that the Samba4 development project has used so far, it did not natrually use the same security subsystems and other resources common the the rest of the AD server. Indeed, at a time before the Franky effort was started, it was not even in the same GIT tree, and certainly not the same build tree.
The merged build
The merged or top level build is the Waf build system. Running ./configure and make at the top level of the source tree will build all of Samba, including the previously Samba3 components. As all duplicate symbol names have been merged, renamed or otherwise dealt with, the merged build has a large number of shared libraries that the whole project builds on, particuarly the IDL genreated file built using PIDL.
Key structures describing the security, authentication and authorization state were changed to be in common. In particuar, key structures like struct auth_session_info and struct security_token now describe the authentication and authorization state across the whole project.
As part of the process of building s3fs, a large number of subsystems were made common, including in particular GENSEC. smbd now uses gensec for all 'blob-based' server-side authentication, in all protocols, which has made it possible to both move to a proper implementation of SPNEGO based on GSSAPI, and allowed the activated plugins to be easily switched for AD DC operation.
With the merged build, it then becomes possible to load or link in plugins for key subsystems, to change the behaviour of the smbd file server, as required for consistency with the rest of the AD server.
perhaps the most key plugin in auth_samba4. This plugin provides 2 very important hooks.
prepare_gensec returns a struct gensec_security that is pre-initialised to use the GENSEC modules that the rest of the AD server uses, including the authentication contexts etc required to authenticate against the AD directory in LDB. When the auth_samba4 module is not in use, the fallback is to the default authentication path, also expressed as a series of GENSEC modules.
make_auth4_context returns a struct auth4_context that similarly operates like the rest of the AD server, for SessionSetupAndX calls that do not use SPNEGO or NTLMSSP.
For operation of smbpasswd, pdbedit and net sam tools, and to assist in the migration of Samba 3.x DC environments to Samba 4.0 AD, a passdb module was written based on pdb_ads from Franky. This module differs in that it directly calls ldb and the associated modules, allowing offline operation when the samba server process is not running. This is particuarly critical for the samba-tool domain samba3upgrade tool.
This module makes the ldb calls required to implement domain DFS referrals on the AD DC, and is loaded for operation on IPC$.
The idmap code in smbd has been modified to accept an ID mapping type of IDMAP_BOTH, representing both a uid and a gid. This will then allow a group (such as Domain Admins) to own a file as a uid, but also be a gid when expressed as group membership.
Currently in s3fs, the winbindd implementation in use is that in the samba binary, from the Samba4 heritige. It shares the same protocol as the Samba3 Winbind in the winbindd binary, but does not implement the full protocol. It also implements a private IRPC based protocol for communication with other parts of the *samba* binary.
s3fs is started by the code in file_server/file_server.c, by writing a private fileserver.conf that includes a preamble of smb.conf options required for operation in this mode, and then it starts the smbd binary by fork() and exec().
At provision time, run
s3fs is tested in the plugin_s4_dc environment in make test. More tests need to be added
s3fs is not currently recommended for use, except where carefully configured by experienced developers or distributors in controlled environments. As we finish some more of this work, we hope to change this status soon.