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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
