Re: Samba

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2006-04-04 at 17:36 +0100, Anne Wilson wrote:
> On Tuesday 04 April 2006 14:15, Craig White wrote:
> > for the record, defaults are what you get when you don't specify
> > anything...
> >
> > from smb.conf
> > Default: workgroup = WORKGROUP
> 
> and as in windows, it is always better to not use the default.
----
It doesn't matter if you use or don't use the defaults unless you
haven't a clue what the defaults are. The easy way to figure out what
the true settings are (explicit and default supplied) is to issue
'testparm -s -v > /tmp/samba.conf' and you can then see all of the
settings, including those supplied by default
----

> > security = share means that there are no users, no home directories and
> > login is a password with access/file permissions as the user specified
> > by smb.conf and thus a user name logging in is pointless when using
> > 'security = share'
> >
> I think we can take it that John Terpstra knows what he is talking about.  
> From "Samba-2 by Example':
> 
> "This installation demands simplicity.  Frequent turn-over of volunteer staff 
> would indicate that a network environment that requires users to logon might 
> be problematic.  It is suggested that the best solution for this office would 
> be one where the user can log onto any PC with any username and password.....
> 
> This oranisation is a prime candidate for Share Mode security."
> 
> He goes on to say that ownership of files created can be forced.
> 
> Note that he is saying that they would not need a password to access the 
> shares.
----
your abbreviation removes the context that would make the last sentence
above meaningful. 'security = share' does not automatically mean there
is no password...only 'guest access = SOME_VALID_USER and guest ok =
yes' can accomplish that.

By the way I am also a member of the samba team and might actually know
what I am talking about.
----
> 
> > The information is available in the man pages for smb.conf should either
> > the OP or the other people trying to help actually want to solve the
> > problem.
> >
> Very little information of this kind is available in the man pages.  There is 
> a lot of information in the original samba.conf file, but if you use swat or 
> webmin to edit the file it will be overwritten and you will never see the 
> useful stuff.  I always rename a copy for safe-keeping before editing.  If 
> anyone needs a copy of the original I'm happy to supply one.
----
this information is very much supplied in the man pages of smb.conf -
see below
----
> 
> > I don't know what the OP is actually trying to accomplish. Is it the
> > ability to access without passwords? security = share would probably be
> > ok but he should set a user and (map to guest = that user) and permit
> > guest (guest ok = yes) on each share. 
> 
> Again, I disagree, based on the authority of JT.
----
Perhaps you are referring to something else then. Security = share does
indeed require a password or adequate guest setup...no other way around
it.
----
> 
> > The section within the man page of 
> > smb.conf 'security = share' completely describes this. 
> 
> There is no such section in the man page, so I presume you are referring to 
> another document.  It would be helpful to know which one.
----
man smb.conf (admittedly this is from FC-4 installation) perhaps you are
having trouble locating the section, which I will now quote...

The different settings will now be explained.

SECURITY = SHARE

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 security = share  server). Instead, the
clients send authentication information (passwords) on a per-share
basis, at the time they attempt to connect to that share.

Note that smbd  ALWAYS uses a valid UNIX user to act on behalf of the
client, even in security = share level security.

As clients are not required to send a username to the server in share
level  security,  smbd  uses  several  techniques  to determine the
correct UNIX user to use on behalf of the client.

A list of possible UNIX usernames to match with the given client
password is constructed using the following methods :

·  If the guest only parameter is set, then all the other stages are
missed and only the guest account username is checked.

·  Is a username is sent with the share connection request, then this
username (after mapping - see username map), is added as a potential
username.

·  If the client did a previous logon  request (the SessionSetup SMB
call) then the username sent in this SMB will be added as a potential
username.

·  The name of the service the client requested is added as a potential
username.

·  The NetBIOS name of the client is added to the list as a potential
username.

·  Any users on the  user list are added as potential usernames.

 If the guest only 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.

If  the guest only parameter is set, or no username can be determined
then if the share is marked as available to the guest account, then this
guest user will be used, otherwise access is denied.

Note that it can be very confusing in share-level security as to which
UNIX username will eventually be  used  in  granting access.

See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION.

Craig


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux