Which files a user may see, and what they can do with those files, can be set on both a server-wide, and per-user basis. The server can also inherit settings from the operating system.
These options may be set in a configuration file or on the command line. They override any per-user settings.
Prevents incoming files from overwriting existing files. Clients must delete an existing file prior to uploading one with the same name.
Prohibits any 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.
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 Site 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 at a time.
When servedat is run as root on a unix system, you may specify system user and group ids in the AuthFile. All actions taken on behalf of the user will be done using those system privileges. In addition, the NoOverwrite, ReadOnly, GetOnly, WriteOnly, WriteListOnly, and RestrictHome options may be turned on for individual users by including them in the AuthFile options field.
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.
When servedat is run as root on a unix system, you may use the SysAuth option to have servedat check the system user database for usernames, passwords, user and group ids, and home directories. System users will also inherit their secondary group memberships. However, you may not set ReadOnly or RestrictHome for individual users inherited from the system.
If you run servedat as root without specifying either SysAuth or AuthFile, it will automatically turn on SysAuth.
If servedat is run as a user other than root, then all accesses will be done using the system privileges that servedat started with. This means that user and group ids will be ignored. On most unix systems, only root can access the system user database.