Access Privileges

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.

Actions which violate server access restrictions will fail with the error "Request Denied" (24 MTP_APP_DENIED).  This is distinct from failures due to filesystem permissions, which instead return "Permission Denied" (27 MTP_APP_PERMISSION).

Server-Wide Settings

These options may be set in a configuration file or on the command line.  They apply to all users unless overriden by an AuthFile record.

GetOnly (-g)
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.

IgnoreModes (-G)
Ignore permission information accompanying uploaded files.  Non-Windows servers will use FileMode instead.

NoOverwrite (-O)
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.

ObjectOnly
Only transactions declaring a valid Object Handler will be permitted.  This effectively disables direct access to the server filesystem.  Not compatible with SyncDat.

ReadOnly (-r)
Prohibits actions which would change the filesystem.

RestrictClients
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.

RestrictHome (-H)
Users may not access files outside of their home directory, with two exceptions.  Folders declared by AllowPath can be accessed as absolute pathnames, and symbolic links will be followed with some limitations.

WriteListOnly (-W)
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.

WriteOnly (-w)
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.

System Settings

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 processes will be launched with that user's identity.  On unix systems, the user's primary and secondary group IDs will also apply.

AuthFile Settings

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 given UID and GID will be used for all accesses and process creations by that user, similar to System Authentication.  A blank or invalid UID or GID field will be replaced with the host system's standard "nobody" ID number.  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

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.