s3-auth: Remove security=share (depricated since 3.6).

This patch removes security=share, which Samba implemented by matching
the per-share password provided by the client in the Tree Connect with
a selection of usernames supplied by the client, the smb.conf or
guessed from the environment.

The rationale for the removal is that for the bulk of security=share
users, we just we need a very simple way to run a 'trust the network'
Samba server, where users mark shares as guest ok.  This is still
supported, and the smb.conf options are documented at
https://wiki.samba.org/index.php/Public_Samba_Server

At the same time, this closes the door on one of the most arcane areas
of Samba authentication.

Naturally, full user-name/password authentication remain available in
security=user and above.

This includes documentation updates for username and only user, which
now only do a small amount of what they used to do.

Andrew Bartlett

                       --------------
                      /              \
                     /      REST      \
                    /        IN        \
                   /       PEACE        \
                  /                      \
                  |      SEC_SHARE       |
                  |    security=share    |
                  |                      |
                  |                      |
                  |       5 March        |
                  |                      |
                  |        2012          |
                 *|     *  *  *          | *
        _________)/\\_//(\/(/\)/\//\/\///|_)_______

4 files changed, 16 insertions, 169 deletions

diff --git a/docs-xml/smbdotconf/security/onlyuser.xml b/docs-xml/smbdotconf/security/onlyuser.xml
index b1ef1b7606..ed1bbd53e3 100644
--- a/docs-xml/smbdotconf/security/onlyuser.xml
+++ b/docs-xml/smbdotconf/security/onlyuser.xml
@@ -3,20 +3,16 @@
                  context="S"
                  xmlns:samba="http://www.samba.org/samba/DTD/samba-doc">
 <description>
-    <para>This is a boolean option that controls whether 
-    connections with usernames not in the <parameter moreinfo="none">user</parameter> 
-    list will be allowed. By default this option is disabled so that a 
-    client can supply a username to be used by the server.  Enabling
-    this parameter will force the server to only use the login 
-    names from the <parameter moreinfo="none">user</parameter> list and is only really
-    useful in <smbconfoption name="security">share</smbconfoption> level security.</para>
+    <para>To restrict a service to a particular set of users you
+    can use the <smbconfoption name="valid users"/> parameter.</para>
+
+    <para>This parameter is deprecated</para>
+
+    <para>However, it currently operates only in conjunction with
+    <smbconfoption name="username"/>.  The supported way to restrict
+    a service to a particular set of users is the
+    <smbconfoption name="valid users"/> parameter.</para>
 
-    <para>Note that this also means Samba won't try to deduce 
-    usernames from the service name. This can be annoying for 
-    the [homes] section. To get around this you could use <command moreinfo="none">user =
-    %S</command> which means your <parameter moreinfo="none">user</parameter> list
-    will be just the service name, which for home directories is the 
-    name of the user.</para>
 </description>
 
 <related>user</related>
diff --git a/docs-xml/smbdotconf/security/security.xml b/docs-xml/smbdotconf/security/security.xml
index 74ea569b86..2575d77b99 100644
--- a/docs-xml/smbdotconf/security/security.xml
+++ b/docs-xml/smbdotconf/security/security.xml
@@ -11,34 +11,18 @@
     Samba and is one of the most important settings in the <filename moreinfo="none">
     smb.conf</filename> file.</para>
 
-    <para>The option sets the &quot;security mode bit&quot; in replies to 
-    protocol negotiations with <citerefentry><refentrytitle>smbd</refentrytitle>
-    <manvolnum>8</manvolnum></citerefentry> to turn share level security on or off. Clients decide 
-    based on this bit whether (and how) to transfer user and password 
-    information to the server.</para>
-
-
     <para>The default is <command moreinfo="none">security = user</command>, as this is
-    the most common setting needed when talking to Windows 98 and 
-    Windows NT.</para>
+    the most common setting, used for a standalone file server or a DC.</para>
 
     <para>The alternatives are
     <command moreinfo="none">security = ads</command> or <command moreinfo="none">security = domain
-    </command>, which support joining Samba to a Windows domain, along with <command moreinfo="none">security = share</command> and <command moreinfo="none">security = server</command>, both of which are deprecated.</para>
-
-    <para>In versions of Samba prior to 2.0.0, the default was 
-    <command moreinfo="none">security = share</command> mainly because that was
-    the only option at one stage.</para>
+    </command>, which support joining Samba to a Windows domain, along with <command moreinfo="none">security = server</command>, which is deprecated.</para>
 
     <para>You should use <command moreinfo="none">security = user</command> and 
     <smbconfoption name="map to guest"/> if you 
     want to mainly setup shares without a password (guest shares). This 
     is commonly used for a shared printer server. </para>
 		
-    <para>It is possible to use <command moreinfo="none">smbd</command> in a <emphasis>
-    hybrid mode</emphasis> where it is offers both user and share 
-    level security under different <smbconfoption name="NetBIOS aliases"/>. </para>
-
     <para>The different settings will now be explained.</para>
 
 
@@ -65,8 +49,6 @@
     the server to automatically map unknown users into the <smbconfoption name="guest account"/>. 
     See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
 
-    <para>See also the section <link linkend="VALIDATIONSECT">NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
     <para><anchor id="SECURITYEQUALSDOMAIN"/><emphasis>SECURITY = DOMAIN</emphasis></para>
 
     <para>This mode will only work correctly if <citerefentry><refentrytitle>net</refentrytitle>
@@ -94,93 +76,9 @@
     the server to automatically map unknown users into the <smbconfoption name="guest account"/>. 
     See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
 
-    <para>See also the section <link linkend="VALIDATIONSECT">
-    NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
     <para>See also the <smbconfoption name="password server"/> parameter and
 	 the <smbconfoption name="encrypted passwords"/> parameter.</para>
 
-    <para><anchor id="SECURITYEQUALSSHARE"/><emphasis>SECURITY = SHARE</emphasis></para> 
-
-    <note><para>This option is deprecated as it is incompatible with SMB2</para></note>
-		
-    <para>When clients connect to a share level security server, they 
-    need not log onto the server with a valid username and password before 
-    attempting to connect to a shared resource (although modern clients 
-    such as Windows 95/98 and Windows NT will send a logon request with 
-    a username but no password when talking to a <command moreinfo="none">security = share
-    </command> server). Instead, the clients send authentication information 
-    (passwords) on a per-share basis, at the time they attempt to connect 
-    to that share.</para>
-
-    <para>Note that <command moreinfo="none">smbd</command> <emphasis>ALWAYS</emphasis> 
-    uses a valid UNIX user to act on behalf of the client, even in
-    <command moreinfo="none">security = share</command> level security.</para>
-
-    <para>As clients are not required to send a username to the server
-    in share level security, <command moreinfo="none">smbd</command> uses several
-    techniques to determine the correct UNIX user to use on behalf
-    of the client.</para>
-
-    <para>A list of possible UNIX usernames to match with the given
-    client password is constructed using the following methods :</para>
-
-    <itemizedlist>
-	<listitem>
-	    <para>If the <smbconfoption name="guest only"/> parameter is set, then all the other 
-	    stages are missed and only the <smbconfoption name="guest account"/> username is checked.
-	    </para>
-	</listitem>
-
-	<listitem>
-	    <para>Is a username is sent with the share connection 
-	    request, then this username (after mapping - see <smbconfoption name="username map"/>), 
-	    is added as a potential username.
-	    </para>
-	</listitem>
-
-	<listitem>
-	    <para>If the client did a previous <emphasis>logon
-	    </emphasis> request (the SessionSetup SMB call) then the 
-	    username sent in this SMB will be added as a potential username.
-	    </para>
-	</listitem>
-
-	<listitem>
-	    <para>The name of the service the client requested is 
-	    added as a potential username.
-	    </para>
-	</listitem>
-
-	<listitem>
-	    <para>The NetBIOS name of the client is added to 
-	    the list as a potential username.
-	    </para>
-	</listitem>
-
-	<listitem>
-	    <para>Any users on the <smbconfoption name="user"/> list are added as potential usernames.
-	    </para>
-	</listitem>
-    </itemizedlist>
-
-    <para>If the <parameter moreinfo="none">guest only</parameter> parameter is 
-    not set, then this list is then tried with the supplied password. 
-    The first user for whom the password matches will be used as the 
-    UNIX user.</para>
-
-    <para>If the <parameter moreinfo="none">guest only</parameter> parameter is 
-    set, or no username can be determined then if the share is marked 
-    as available to the <parameter moreinfo="none">guest account</parameter>, then this 
-    guest user will be used, otherwise access is denied.</para>
-
-    <para>Note that it can be <emphasis>very</emphasis> confusing 
-    in share-level security as to which UNIX username will eventually
-    be used in granting access.</para>
-
-    <para>See also the section <link linkend="VALIDATIONSECT">
-    NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
     <para><anchor id="SECURITYEQUALSSERVER"/><emphasis>SECURITY = SERVER</emphasis></para>
 
     <para>
@@ -221,9 +119,6 @@
     the server to automatically map unknown users into the <smbconfoption name="guest account"/>. 
     See the <smbconfoption name="map to guest"/> parameter for details on doing this.</para>
 
-    <para>See also the section <link linkend="VALIDATIONSECT">
-    NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
     <para>See also the <smbconfoption name="password server"/> parameter and the 
 	<smbconfoption name="encrypted passwords"/> parameter.</para>
 
diff --git a/docs-xml/smbdotconf/security/serverrole.xml b/docs-xml/smbdotconf/security/serverrole.xml
index 5832887040..e4e65c297b 100644
--- a/docs-xml/smbdotconf/security/serverrole.xml
+++ b/docs-xml/smbdotconf/security/serverrole.xml
@@ -51,9 +51,6 @@
     exist as well as the account on the Domain Controller to allow 
     Samba to have a valid UNIX account to map file access to.  Winbind can provide this.</para>
 
-    <para>See also the section <link linkend="VALIDATIONSECT">
-    NOTE ABOUT USERNAME/PASSWORD VALIDATION</link>.</para>
-
     <para><anchor id="DC"/><emphasis>SERVER ROLE = DOMAIN CONTROLLER</emphasis></para>
 
     <para>This mode of operation runs Samba as a domain controller, providing domain logon services to Windows and Samba clients of the domain.  Clients must be joined to the domain to create a secure, trusted path across the network.</para>
diff --git a/docs-xml/smbdotconf/security/username.xml b/docs-xml/smbdotconf/security/username.xml
index 19d8a2ecfd..a85076c737 100644
--- a/docs-xml/smbdotconf/security/username.xml
+++ b/docs-xml/smbdotconf/security/username.xml
@@ -5,57 +5,16 @@
 <synonym>user</synonym>
 <synonym>users</synonym>
 <description>
-    <para>Multiple users may be specified in a comma-delimited 
-    list, in which case the supplied password will be tested against 
-    each username in turn (left to right).</para>
-
-    <para>The deprecated <parameter moreinfo="none">username</parameter> line is needed only when 
-    the PC is unable to supply its own username. This is the case 
-    for the COREPLUS protocol or where your users have different WfWg 
-    usernames to UNIX usernames. In both these cases you may also be 
-    better using the \\server\share%user syntax instead.</para>
-
-    <para>The <parameter moreinfo="none">username</parameter> line is not a great 
-    solution in many cases as it means Samba will try to validate 
-    the supplied password against each of the usernames in the 
-    <parameter moreinfo="none">username</parameter> line in turn. This is slow and 
-    a bad idea for lots of users in case of duplicate passwords. 
-    You may get timeouts or security breaches using this parameter 
-    unwisely.</para>
-
-    <para>Samba relies on the underlying UNIX security. This 
-    parameter does not restrict who can login, it just offers hints 
-    to the Samba server as to what usernames might correspond to the 
-    supplied password. Users can login as whoever they please and 
-    they will be able to do no more damage than if they started a 
-    telnet session. The daemon runs as the user that they log in as, 
-    so they cannot do anything that user cannot do.</para>
-
     <para>To restrict a service to a particular set of users you 
     can use the <smbconfoption name="valid users"/> parameter.</para>
 
-    <para>If any of the usernames begin with a '@' then the name 
-    will be looked up first in the NIS netgroups list (if Samba 
-    is compiled with netgroup support), followed by a lookup in 
-    the UNIX groups database and will expand to a list of all users 
-    in the group of that name.</para>
-		
-    <para>If any of the usernames begin with a '+' then the name 
-    will be looked up only in the UNIX groups database and will 
-    expand to a list of all users in the group of that name.</para>
-
-    <para>If any of the usernames begin with a '&amp;' then the name 
-    will be looked up only in the NIS netgroups database (if Samba 
-    is compiled with netgroup support) and will expand to a list 
-    of all users in the netgroup group of that name.</para>
+    <para>This parameter is deprecated</para>
 
-    <para>Note that searching though a groups database can take 
-    quite some time, and some clients may time out during the 
-    search.</para>
+    <para>However, it currently operates only in conjunction with
+    <smbconfoption name="only user"/>.  The supported way to restrict
+    a service to a particular set of users is the
+    <smbconfoption name="valid users"/> parameter.</para>
 
-    <para>See the section <link linkend="VALIDATIONSECT">NOTE ABOUT
-	USERNAME/PASSWORD VALIDATION</link> for more information on how 
-	this parameter determines access to the services.</para>
 </description>
 
 <value type="default"><comment>The guest account if a guest service,