[Samba] Proposal to change security=share in Samba 4.0

[Mike Rambo]

Andrew Bartlett wrote:
> On Mon, 2012-02-27 at 19:45 -0500, simo wrote:
>> On Tue, 2012-02-28 at 10:16 +1100, Andrew Bartlett wrote: 
>>> On Mon, 2012-02-27 at 17:53 -0500, David Collier-Brown wrote:
>>>
>>>> Am I correct in thinking this would make all shares have the same
>>>> password as the guest user, or do you mean there really is no password
>>>> at all, or alternatively that one would specify the share, provide
>>>> it's password and be logged on as guest???
>>>>
>>>> It's been a while since I had a security=share setup, but I remember
>>>> WfW clients thinking that they had per-share passwords...
>>> In the past, Samba tried to match the 'per share' password provided by
>>> the client against a list of users, falling back to guest if 'guest ok =
>>> yes' was set on the share.
>>>
>>> What will happen now is that the password will be ignored, and only the
>>> 'guest ok' will be checked, and access will be as guest.
>> This in effect means dropping security = share, can't we just
>> effectively drop it instead of deceiving our users and making them
>> believe they are using it ?
> 
> I am fully in support of dropping it.  
> 
> Kai asked that we still have a way to 'simply' configure the system for
> trivial file access.  These semantics (guest only) broadly matches the
> default file sharing access on WinXP.  (Windows 7 instead wants you to
> use a HomeGroup, and makes just sharing a folder with no pw
> substantially more difficult).
> 
> If the consensus of the list is to drop it outright, and simply error on
> parsing security=share, I will prepare a patch to do that.  
> 
> The recommended simple sharing option of 'map to guest = bad user'
> naturally remains.
> 
> Thanks,
> 
> Andrew Bartlett
> 

FWIW.

It's interesting that this comes up now. We (a school district in MI US) 
are now part way though the process of deploying about 25 boxes in our 
various buildings one of the purposes for which will be a simple sharing 
of "public" access space for users within a given building. Our goal was 
to have no user/password overhead and security (with the term applied 
loosely) is merely to limit access to the share to the network subnet 
the building lives in (all of our buildings have individual subnets). 
These shares are publicized as basically temporary scratch pads which 
are not backed up or supported in any way other than simply being there.

In spite of that potentially transient nature they are still used heavily.

 From what I saw in the rest of the thread it looks like there will 
still be a way to do this but I thought I'd chime in since the subject 
has come up and we do use security=share to accomplish this at present.


Regards,

--
Mike Rambo