One of the ways the Server can control who has access, is through the use of a private authentication file, or AuthFile. The file consists of plain text lines, each specifying a username, password, and other options. An AuthFile is also the preferred method to enable Anonymous Access.
A sample AuthFile, named svpasswd, is included in the "Server Files" folder.
An AuthFile is activated by specifying its path with the AuthFile configuration variable or the "-A <password-file>" command line option. The recommended location in Windows is "%SYSTEMROOT%". An "Install svpasswd.bat" script is included which will copy the example svpasswd.txt file into that location after you are done editing it. For unix systems, "/etc" or "/usr/local/etc" are recommended locations.
Specifying an AuthFile will change the default setting of SysAuth to disabled. If you require system authentication, be sure to explicitly enable it before enabling an AuthFile.
The contents of the file must be plain text with each line containing no more than 255 characters and the following colon separated fields:
Username : Password : UserId : GroupId : HomeDir : Options
|Username||Up to 31 characters that will be matched against the username given by the client. It is best to avoid special characters and spaces. The first match will be used and a username found here will override any listing in the system database.|
The plain or hashed text that the client's password must match. Password hashes can be generated using mkpasswd and are recommended for security. Unix systems require that a hash be a unix crypt string, while Windows systems require that a hash be 128-bit MD5.If this field is 13 or 32 characters it will be interpreted as a crypt or MD5 hash.
|UserId||If you specify a system user id number here, then all accesses matching Username will be performed with the privileges of this user id. Note that servedat must be started as root to set user ids. The value -1 is not valid on most systems and will be mapped to INT_MAX or UNINT_MAX. This field is ignored in Windows.|
|GroupId||If you specify a system group id number here, then all accesses matching Username will be performed with the privileges of this group id. Note that servedat must be started as root or as a user belonging to the given group id. The value -1 is not valid on most systems and will be mapped to INT_MAX or UNINT_MAX. This field is ignored in Windows.|
|HomeDir||You may specify a Home Directory for the Username. Leave this blank to use servedat's default home directory. As a special case, the Windows version will allow volume labels like "D:\path", even though this use of a colon violates the field delimiting.|
|Options||This is a comma separated list of additional per-user options. See Access Privileges for more details.|
|ReadOnly||Prohibits any actions which would change the filesystem.|
|GetOnly||Permits only individual file downloads (with or without compression). All other actions, including directory listings, are forbidden. Useful for providing users with targeted downloads via expedat:// URLs. Not compatible with SyncDat.|
|WriteOnly||Allows only file uploading and related actions. Files cannot be downloaded and directories cannot be listed. This may be useful in creating drop-boxes to be shared amongst semi-trusted users. Not compatible with SyncDat.|
|WriteListOnly||Allows only directory listings, file uploading, and related actions. Files cannot be downloaded. Similar to WriteOnly except that users can see what files are already on the server.|
|If more than one of ReadOnly, GetOnly, WriteOnly, or WriteListOnly is enabled for a user, either due to individual or server-wide settings, then the most restrictive intersection of them will be enforced. This can result in a user having effectively no privileges.|
|NoOverwrite||Prevents incoming files from overwriting existing files. An existing file must be deleted prior to uploading one with the same name.|
|RestrictHome||Prohibits access to files outside of the home directory, with two exceptions. Folders declared by AllowPath can be accessed as absolute pathnames. On non-Windows systems, symbolic links will be honored with some limitations. RestrictHome is always enabled for the ANONYMOUS user, even if it is not specified here.|
|ObjectOnly||Prevents direct access to the filesystem: all transactions must declare a valid Object Handler.|
See the enclosed svpasswd sample file for an example of formatting. Note that servedat will not start if it is unable to parse the private authentication file. For the best security, be sure to locate this file outside of the default home directory, set its permissions so that access is restricted to trusted users, and use mkpasswd to generate password hashes instead of using plain-text.
The AuthFile is read at startup or restart. On unix systems, sending the HUP signal to a running servedat process will cause it to restart and reload all of its settings. On Windows systems with servedat in service mode, the service manager can be used to restart servedat. Any active transactions will be interrupted by such a restart, however most clients will automatically retry in about a minute.
If a username in the AuthFile matches that of a system user, then the AuthFile record will be used in place of the system settings.
On unix-like systems, each AuthFile user will operate with the user and group id specified. This will allow authenticated access on NFS filesystems. Other network attached storage, such as CIFS or AFP, may deny access to AuthFile users if they are configured to require authentication. See Tech Note 0031 for more about NAS authentication.
On Windows, each AuthFile user will operate with the privileges of servedat itself. It is therefore important to make use of options such as RestrictHome for Windows AuthFile users. Network attached storage may deny access to AuthFile users if it has been configured to require its own authentication. See Tech Note 0031 for more about NAS authentication.