Quick Summary

Sharity requires that you log in with username and password at the server before you can access any resources.

The directory /CIFS is similar in functionality to the "Network Neighborhood" on Windows computers.

4. General Concepts

Most Unix users are familiar with NFS for sharing files in the network. Although CIFS serves the same purpose as NFS, there are some subtile differences. This chapter is dedicated to those differences.

4.1 Login to Servers

With NFS things are simple: You mount an exported share and all local users have access to the mounted files. However, you have to pay a high price for this simplicity: The local machine, the client, is responsible for checking access permissions. The server simply has to trust the client to do this job correctly. Everyone who runs a malicious client, which performs faked permission checks, has access to all files with almost arbitrary rights.

The situation is different with CIFS. The clients have to prove to the server that a file access comes in fact from a particular user. This proof is carried out by logging in each user at the server with username and password (the credentials) [unless your server is in share-level security mode, see later]. A malicious client can only gain access with the privileges of a user who's credentials it knows.

The difference for the user is that he or she has to provide credentials before doing any access. If you run the Sharity GUI application, this task is made more transparent for you: Whenever you access a server where you are not already logged in, a panel pops up asking you for your remote username and password. These credentials are then used to log you in at the server. If you don't run the GUI, you have to use the commandline tool cifslogin before accessing data. This is how to tell Sharity about your credentials if it has no way to ask. By the way: The user who mounted the share is automatically logged in during the mount. It's worth noting that you can login as any user you like on the server (e.g. Administrator), as long as you know the appropriate username and password.

4.2 Mounting Servers

The process of mounting a server is very similar to NFS. Here's the list of differences:

The mount requires login-credentials for the server. You therefore have to supply a username and password for the mount. The Unix user who performs the mount is automatically logged in at the server with the credentials he or she gave.
There's only a two-level hierarchy for network resouces: a server name and a share name within the server context. Share names are assigned to directories by the server administrator when they are exported. You can't do such a thing as mounting a subdirectory of an exported share.
Server names are Netbios names. You can't use the IP address or the DNS (Domain Name Service) name, unless it's the same as the Netbios name. This version of Sharity uses Netbios and DNS for name resolution. It first tries to find the server's IP address through the Netbios Name Service (called WINS by Microsoft). If this fails, it tries DNS. If both methods fail, you can explicitly configure an IP address for the server.

4.3 Accessing Files

While there is no problem with file contents (a file is a file on Windows and on Unix...), the attribute system differs quite a lot between CIFS and NFS. NFS is modelled after the Unix file attributes consisting of the file's owner, group, specific permissions and modification dates. The CIFS attributes are much simpler: There's no file owner or group and hence no owner- and group-specific permissions. Inherited from the DOS era are the file flags hidden, system, archive, write-protect, etc. There is an extension to CIFS which allows file attributes with Access Control Lists (ACLs) as they are used by Windows NT, but these extensions are not documented in the CIFS specification.

Sharity has to perform a useful mapping between the Unix and the CIFS file attributes. The mapping is as follows:

Owner: All files belong the the user who accesses them. This is necessary because Unix allows only the owner of a file to change attributes.

Group: The group of all files is the default group of the accessing user.

Permissions for Owner: The read permission is always on and the write permission is taken from the read-only DOS file attribute. The execute permission can be mapped to any remaining DOS file attribute in the configuration.

Permissions for Group and Others: These permissions are copied from the owner's permissions. The access permissions have no meaning security-wise. The security check is performed by the server based on the accessing user's credentials.

File Modification Time: This time has a direct correspondence in CIFS, although the granularity of the time scale depends on the CIFS subdialect negotiated with the server. It's likely that times can be stored in two second resolution only.

File Read Time: Not all CIFS dialects provide this attribute. If it's not available, the modification time is substituted instead.

Last Inode Change Time: There's no such thing as an inode in CIFS and hence no such attribute. Sharity substitutes the file creation time, if it is available or the modification time otherwise.

CIFS has no equivalent for Unix specialities like symbolic links, hard links, Unix domain sockets, device files etc. These things can't be created in a Sharity mounted directory. However, since symbolic links are so important in a Unix environment, Sharity can fake them. This feature is off by default and can be enabled in the configuration. Faked symbolic links are stored as ordinary files on the server containing a magic number and the path where the link points. These files differ from ordinary files in their DOS attributes: They have the system- and the hidden-attribute set and must not be read-only.

4.4 If the Server is in Share-Level Security Mode

In "Share-Level Security Mode" passwords are assigned to shares, not to users. This means that you don't need an account on the remote machine. You only have to know the share's password to access it. Sharity copes with this situation in the following way:

The commandline tools cifsmount and cifslogin and the GUI don't require a remote username, they only ask for the share password. However, cifslogin needs a share name, contrary to user-level security mode.
Users who access the share are asked for the share password by the GUI. If they are the first user to access the share, the share password is validated with the server. If the share is already mounted, the given password is compared to the password used by the user who mounted the share.
cifslist and the GUI display the remote username <none>, since the server has no concept of usernames.

4.5 Browsing

Sharity supports the Browsing extensions to CIFS. "Browsing" has nothing to do with a web-browser, it is the possibility to retrieve a list of available network resources from the network. In other words: You don't need to know the server- and share-name beforehand, you can browse them in a listing.

The browsing facility is represented by a Browser in Sharity. You can mount a browser in the same way as you can mount a remote file share. Below the browser mountpoint is a two-level deep hierarchy of server names and share names. Once you get to the share name, Sharity automatically mounts the share at a private place and redirects you to this new mountpoint by means of a symbolic link.

Browsing is a very nice feature, but it must be set up correctly in order to work. This is not always easy and we will therefore explain how browsing works. The first thing a client has to do is to get the list of file servers. This list can be obtained from a Browse Server. There's at least one Browse Server for each workgroup or domain. There must also be at least one Browse Server in each network segment. A network segment (or broadcast area) consists of all machines which can be reached without going through a router. Sharity needs to know the Local Master Browser. This is the Browse Server in Sharity's network segment. It can be found by broadcasting a Netbios name lookup for the domain or workgroup name. Once we know the Local Master Browser, we can ask it for the list of file servers, look up the IP addresses for these servers by means of the Netbios Name Service and then ask these file servers for their list of exported shares.

From the above explanation you can see that browsing depends on

knowing the workgroup or domain name
having at least one Browse Server in your network segment
having the netbios name lookup work properly (WINS configuration)

If you don't know what to configure for the workgroup/domain name and the Netbios Name Server (WINS server), you can look these things up in the network configuration of a (working) Windows client.

Each Windows machine can become a Browse Server, if required. You don't have to worry about the Browse Server if there are Windows machines in your network segment which are always up and running. If you can't guarantee this, e.g. if you have separated network segments for Unix and Windows, you need a CIFS server on at least one Unix machine which can provide the Browsing Service. Samba beginning with version 1.9.17 can do this. It may therefore be necessary to install Samba on at least one Unix machine in every network segment to make browsing work. You allow Samba to become the Local Master Browser by setting

    local master = yes

in the configuration file smb.conf. For more information about browsing, please read the (more technical) documentation distributed with Samba in the file:

    docs/textdocs/BROWSING.txt

or the more user-friendly overview in

    docs/textdocs/BROWSING-Config.txt