Sams Teach Yourself Samba in 24 Hours
Hour 7: File Sharing
Previous
Hour
|
Sections in this Chapter: |
|
|
|
||
|
||
|
||
|
||
|
||
|
|
Sams Teach Yourself Samba in 24 Hours |
|
||||||||||||||||||||||
|
Hour 7: File Sharing |
|
||||||||||||||||||||||
|
|
||
|
Now that you have created a file share, you need to make it more usable. For example, browse the file share (after making it browsable again in your smb.conf file; don't forget to stop and restart Samba). Then try to copy a file into the file share, or create a new file or directory in the file share. You should find that you can't. You will now explore the reasons for that and how to change it.
The file share is great for sharing files that have been put into the file share directory by users with sufficient access rights, but client workstations cannot create files in the share. Even if you log in as root (the superuser under UNIX) you are unable to create files in the share as yet. As you will soon see, the share is read-only by default.
In order to allow clients access to the file share, you must tell Samba a few things about the file share. First, however, you must look at how Samba determines whether a client can have access to file shares.
In Hour 2, "Windows Networking," you looked at the way in which a CIFS/SMB client accesses a resource, or file share, on a server. To refresh your memory, the following steps occur, although some can be skipped:
1. The client negotiates a protocol variant to establish which variant of the CIFS/SMB protocol it understands.
2. The client might then do a logon to the network or server, depending on the protocol variant being used and the presence of logon servers. At this point the client provides a username and a password, but this step can be skipped, especially for old clients.
3. The client requests a connection to a tree, or share.
To process the client's request to connect to a share, Samba first determines whether the requested share exists. The following simple approach determines whether it does:
1. Scan the smb.conf file looking for a section that matches the requested share name. If one is found, use it.
2. If the share is not found, check to see whether it contains a [homes] section in the smb.conf file. If so, check the passwd file to see whether the share name matches a user name. If it does, the [homes] share is cloned (as detailed later in this hour), and the new share is used.
3. If the share is still not found, check to see whether the smb.conf file contains a [printers] section. If so, check whether the requested share matches a printer in the printcap file. If it does, clone the [printers] share and use the cloned share. The [printers] section is discussed in more detail in Hour 8, "Printers."
4. If the share is still not found, check whether a default service exists and, if so, change the default service name to match the requested service and use it.
5. If no share is found, Samba returns an invalid network name error to the client.
Next, Samba uses the following procedure to determine whether a client should be given access to the share found, and who they will be given access as. The steps are tried in order, with the process terminating successfully with the first step that succeeds. If all the steps fail, access to the share is denied.
1. If the client has submitted a username/password pair that validates, access is allowed to the share as the validated user. Some older clients can submit their usernames using the \\server\service%username syntax.
2. If the client has already submitted a valid username and now supplies a correct password (on the share request), access to the share is allowed as the validated username.
3. The client's NetBIOS name and any previously used usernames are validated using the operating system's standard mechanisms (or the smbpassword file) with the supplied password. If any validate successfully, access to the share is allowed as the validated username.
4. If the client has previously validated a username/password pair with the server (using a SessionSetupandX) and the client passed the validation token in the share access request, access to the share is allowed as the username indicated in the token. This step is skipped if the share specifies revalidation (revalidate = yes).
5. If a user = field has been specified on the share, the client has supplied a password, and the combination of username specified in the share and password validates, access to the share is allowed as the specified user.
However, if the service is a guest only service, access to the service is allowed as the username specified as the guest account without going through any of the preceding steps. Any supplied password is ignored.
If the user chosen as the accessing user is in an invalid user list (described later this hour), the request to connect to the share is rejected at this point.
This procedure allows Samba to determine under which account access to files in the share is allowed. However, access to shares and the mode of access to files allowed is further controlled by a number of parameters in the smb.conf file.
The following parameters affect access to shares by clients in one way or another. Most Samba administrators do not use many of these parameters. As always, the final list of such parameters and the final word on their function rests with the manual pages on smb.conf for the current version of Samba. You should use man smb.conf to check these parameters.
This share-level parameter sets the users who are granted administrative privileges for the share. When they access the share, they do all file operations as root.
Names starting with @ are interpreted as an NIS netgroup and then as a UNIX group if not found in NIS. Names starting with + are interpreted as UNIX groups, whereas names starting with & are interpreted as NIS groups.
This parameter can be very dangerous, as any user in the admin users list can do anything they want, including deleting all files in the share.
By default, there are no administrative users for a share. An example of using this parameter is
admin users = root, fred
which specifies that root and fred are admin users.
This global parameter sets the name of the default service. The default service is used if the share requested by a client cannot be found. If the default service is used to satisfy a share connection request, its name is changed to match the requested share.
Typically, the default service would have the parameters guest ok and read only set.
This parameter has no default value. An example of using this parameter is
default service = lastchance
which sets the default service to the service called lastchance.
This global parameter sets the name of the guest account. It is often set to pcguest and must exist in whatever account database is used on the server (for example, passwd file, NIS, and so on). Typically, this account doesn't have a valid password, so no one can log in to it, either from UNIX or from a client. The account can be used only to control access to files.
This parameter can be set in the global section and in individual share sections. Guest accounts specified in a share section override any global one.
The default for this parameter is specified at compile time, and it set to nobody by default. An example of using this parameter is
guest account = pcguest
which specifies that the account called pcguest should be used as the guest account.
This share-level parameter specifies whether access to a share can be obtained without submitting a username and password.
When clients are granted guest access, they access files under the share as the guest account.
A synonym for guest ok is public.
The default value for this parameter is no. An example of using this parameter is
guest ok = yes
which specifies that it is permissible to access the share using the guest account.
This share-level parameter specifies that only guest connections are allowed to aparticular share. It must be used in conjunction with guest ok or public.
The default value for this parameter is no. An example of using this parameter is
guest only = yes
which specifies that this service can only be accessed using the guest account.
This parameter sets the list of hosts that are allowed to access services. If set in the global section, it applies to all services, regardless of any setting specified by individual services. If not set in the global section, it can be set for individual services.
Hosts can be specified by name or IP number. The full syntax for this parameter is the same as that in the TCP Wrappers hosts_allow file. Please check the man pages (man hosts_allow) for more details.
There is no default value for this parameter. An example of using this parameter is
hosts allow = 192.1.1. graham.goodies.com
which specifies that any host in the subnet 192.1.1.0/24 can access the share as well as the system called graham.goodies.com.
This parameter is the opposite of hosts allow. Hosts listed in this parameter are not allowed to access services unless a specific service overrides this list with their own list of allowed hosts. When the hosts deny and hosts allow parameters conflict, hosts allow takes precedence.
There is no default value for this parameter. An example of using this parameter is
Hosts deny 192.1.1. badhost.bad-company.com
which specifies that access to the share is not allowed for any host in the subnet 192.1.1.0/24 as well as badhost.bad-company.com.
This share-level parameter specifies a list of users that should not be allowed to access the service. This parameter uses the same syntax as admin users preceding.
There is no default value for this parameter. An example of using this parameter is
invalid users = root fred@bin
which specifies that the users root, fred, and any user in the group bin are not allowed to access the share.
This share-level parameter specifies the maximum number of clients that can connect to the share. If set to a value greater than 0, no more clients are allowed to access the share after the specified maximum number of users has connected to the share. When the number of connected users drops below the specified value, new connections are allowed up to the specified maximum. If set to 0, no limits are placed on the number of connections that can be made.
This parameter can limit the load on a Samba server and can also provide a measure of license usage enforcement if you are sharing licensed software. Be aware that you are limiting the number of connected users, not the number of active users. Also a user who connects to the share at the beginning of the day and stays connected all day while doing nothing still consumes one of those max connections.
The default value for this parameter is 0, which, as stated before, allows unlimited connections to the share. An example of using the share is
max connections = 100
which specifies that no more than 100 connections are allowed to the share.
This share-level parameter is a list of the users who are given read-only access to the share. That is, they are not given write access to the share, even if the share is writable.
There is no default for this parameter. An example of using this parameter is
read list = fred @guests
which specifies that fred and all the users in the group guests are given read-only access to the share. That is, they are unable to write it.
This share-level parameter is the opposite of writable. When set, it indicates that clients may not write to a share.
By default, this parameter is yes, which means that the share is read-only. That is, if you do not provide a value for a share, it is read-only. An example of using this share is
read only = no
which means that the share can be written. An alternative way of specifying the same is
writable = yes
This share-level parameter lists the users who are allowed to access the file share. It uses the same syntax as admin users.
By default, this parameter is empty, which means that any user can access the share. An example of using this parameter is
valid users = fred @accounts
which specifies that the user fred and all users in the accounts group are the only ones allowed to access the share.
This share-level parameter (and its synonym writeable for those who can't spell) indicates whether clients can write to the share. See also read only.
By default, this parameter is set to no, which means that a share is read-only by default. Examples of using this share are
writable = yes writeable = yes read only = no
which all specify that the share may be written to by anyone who has the permission write to the files and directories in the share.
This share-level parameter specifies a list of users who are given read-write access to a share, despite the value of the read only parameter.
If a user is in both the read list and the write list, he is given write access.
By default, this parameter has no value, which means that all users are governed by the value of the read only parameter. An example of using this parameter is
write list = root @admin
which specifies that at least the user root and all the users of the admin group have write access to the share.
Now that you have looked at the parameters that affect accessibility of shares, you are ready to fix the problems you encountered in accessibility earlier, where you could not write to your first-share.
This problem arose because, by default, a share has
writable = no
set. To see that neither file nor directory privileges are causing the problem, look at the UNIX privileges for the directory that is shared, and then change them to world RWX (0777 for simplicity). Unless you have changed your umask, /home/first-share on your Samba server looks like this:
ls -al /home/first-share total 4 drwxr-xr-x 2 root root 1024 Jan 5 14:23 . drwxr-xr-x 17 root root 1024 Jan 5 14:23 .. -rw-r--r-- 1 root root 69 Jan 5 14:22 file-1.txt -rw-r--r-- 1 root root 59 Jan 5 14:23 file-2.txt
Now, change the permissions on the directory to 0777 with
chmod 0777 /home/first-share
This should allow any UNIX user to write to the directory, as it sets group and world (other) read, write, and execute access.
But, when you try to create a file in the share from your client, you get what's shown in Figure 7.8.
Figure
7.8
Access is denied, despite the directory being wide open.
If you add the following to your first-share (and restart Samba), you can allow clients to write to the share:
writable = yes
Try it! You now can create directories and files in the share, as shown in Figure 7.9.
Figure
7.9
With the share writable, you can create folders in it.
Over on the Samba server, your shared directory now looks like this:
ls -al /home/first-share total 4 drwxrwxrwx 2 root root 1024 Jan 5 14:23 . drwxr-xr-x 17 root root 1024 Jan 5 14:23 .. drwxr-xr-x 2 boss boss 1024 Jan 6 01:09 New Folder -rw-r--r-- 1 root root 69 Jan 5 14:22 file-1.txt -rw-r--r-- 1 root root 59 Jan 5 14:23 file-2.txt
Your New Folder has been created as a directory and is owned by you, with group owner as your group. But this is possible only because you set the directory /home/first-share to mode 0777, which is quite dangerous.
You could set many of the other parameters to affect access to first-share, including
As an example, your share might become
){kind=link}
){kind=link}
[first-share]
comment = My first share
path = /home/first-share
browsable = yes
writable = yes
valid users = boss joe +users
write list = root boss
This modifies first-share to specify that boss, joe, and any user in the UNIX group users can access the share, whereas only boss and fred can write to the share.
Now you must look at how file permissions are handled by Samba, so you can see how UNIX file permissions interact with requests to read or write files.
|
Sams Teach Yourself Samba in 24 Hours |
|
||||||||||||||||||||||
|
Hour 7: File Sharing |
|
||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.