Client access rights are determined by a combination of the server-wide security options and the authenticated user account. Server-wide settings apply access restrictions to all users. System Authenticated users inherit access rights from the matching operating system account. Access rights for Private Authenticated users are determined by their AuthFile record.
These options may be set in a configuration file or on the command line. They apply to all users.
Prevents incoming individual files from overwriting existing files. Clients must delete an existing file prior to uploading one with the same name. Does not apply to the contents of Streaming Folders.
Prohibits actions which would change the filesystem.
Permits only individual file downloads (with or without compression). All other actions, including directory listings, are forbidden. It is a more restrictive form ReadOnly, useful for providing users with targeted downloads via expedat:// URLs. Not compatible with SyncDat.
Only transactions declaring a valid Object Handler will be permitted. This effectively disables direct access to the server filesystem. Not compatible with SyncDat.
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.
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.
Only clients with a SiteOptions declaration will be allowed to perform transactions with this server. All other clients will be denied, regardless of their credentials.
No user may access files outside of their 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.
Only one of ReadOnly, GetOnly, WriteOnly, or WriteListOnly may be enabled server-wide. However, it is possible for server-wide settings to overlap with AuthFile settings such that a user may have effectively no privileges.
When servedat is run with sufficient privileges, it can access the host operating system's authentication databases. Operations performed using system credentials will inherit whatever privileges and limitations are assigned by the operating system. Access rights will be similar to if the same user were logged into a shell or console. These rights are further restricted by server-wide settings.
If you run servedat as root or as a Windows Service without specifying either SysAuth or AuthFile, then SysAuth will be automatically enabled.
Uploaded files will be owned by the authenticated system user, and any Object Handler or Packaging processes will be launched with that user's identity. On unix systems, the user's primary and secondary group IDs will also apply.
The private authentication database, or AuthFile, allows you to establish user credentials independent of the operating system. Restrictions similar to the server-wide settings can be applied to individual private authentication users.
On unix systems, each AuthFile user may be assigned a system user id and group id. If servedat is run as root, then the UID and GID will be used for all accesses and process creations by that user, similar to System Authentication. If servedat is running unprivileged, then the UID and GID given will be ignored and all accesses will occur with servedat's credentials.
On Windows systems, AuthFile user credentials are the same as that of the servedat process. For this reason, it generally desirable to use either server-wide or individual restrictions such as RestrictHome to maintain system security.