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 AuthFile users, including shadowed system users, may be further restricted by their AuthFile record.
Permits only individual file downloads (with or without compression). All other actions, including directory listings, are forbidden. It is a more restrictive form of ReadOnly, useful for providing users with targeted downloads via expedat:// URLs. Not compatible with SyncDat.
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.
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.
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.
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.
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 in such a way that a user has effectively no access. For example, if ReadOnly is set server-wide and WriteOnly is set for an individual user, that user will have no access.
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.
Uploaded files will be owned by the authenticated system user, and any Object Handler 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.
AuthFile records can also be used to shadow system user accounts, applying individual home directory and restriction settings.
On unix systems, each private 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, private AuthFile user credentials are the same as that of the servedat process. Shadow Authentication users run with the privileges of the corresponding system user.
Object Handlers are executed with the same privileges as described for file access above. System and shadow users run handlers with their system identity, private AuthFile users run with servedat's identity on Windows or the given UID/GID on all others.
The access restrictions described above are reported to the object handler, but it is the responsibility of the handler itself to interpret and enforce them.