GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  PRIVMAN_CONF (5)

NAME

privman_conf - configuration file format for Privman managed applications

CONTENTS

Synopsis
Description
Bugs
Author

SYNOPSIS

${prefix}/etc/privman.d/appname

DESCRIPTION

Each application has its own configuration file in ${prefix}/etc/privman.d that described the privileges that the application has. The default behavior is to deny all requests: only by adding privileges to the file will any requests be permitted.

As is normal for Unix configuration files, comments start from the # character to the end of the line. Whitespace can be liberally used, the file format depends on the grammar for structure, not whitespace.

There are currently ten different privilege types.

open_ro { /path/to/file

/path/to/directory/*

}

Lists files that the application can open read-only. Currently the path elements are not allowed to contain whitespace, or the character ’*’. If a path ends with a ’*’ as the final path element, then any file in that directory can be opened.

open_rw { }

Lists files that the application can open read-write. See open_ro for more detail.

open_ao { }

Lists files that the application can open append-only. See open_ro for more detail.

unlink { }

Lists files that the application can unlink (delete). See open_ro for more detail.

bind { 80

}

List any privileged port the application needs to bind to here. If you only need one port, you can dispense with the curly braces. Ports can be specified numerically, or by name. If specified by name, the port will be converted to a number by gethostbyname(). The wildcard character ’*’ is accepted as a port, in which case the application will be permitted to bind to any port.

run_as { user

}

The application can invoke priv_execve or priv_rerunas as the specified users. To allow the application to change to any non-root user, use the wildcard character ’*’. To also allow the application to change to a root user, specifically mention the root user in the user list.

chroot /path/to/jail

The chroot jail the unprivileged portion of the program runs in after priv_init. This option defaults to /.

unpriv_user nobody

The unprivileged user the program runs as after priv_init. This user is also the default user for priv_rerunas and priv_execve. This option defaults to nobody.

auth (true|false)

Determines whether the application is allowed to use PAM authentication. This will not, by itself, allow the application to change user ID. It merely allows the application to invoke PAM to authenticate the user. This option defaults to false.

auth_allow_rerun (true|false)

If this is set to true, and user that successfully authenticates via PAM authentication will be added to the run_as list for this execution of the program. Using this primitive allows you to keep the run_as list much shorter, possibly empty. This option defaults to false.

fork (true|false)

The application is allowed to use priv_fork() or priv_daemon(). See priv_fork(3) or priv_daemon(3) for more detail. This option defaults to false.

allow_rerun (true|false)

The application is allowed to use priv_rerunas() and priv_respawn_as(). See priv_rerunas(3) for more detail. This option defaults to false.

BUGS

The mapping between the configuration file and the policy as enforced by the Privman server process may not be exact. In particular, a user might want to enforce (program,user,chroot) tuples, but the configuration file provides no way to do this.

The characters allowed in path lists are a distinct subset from the characters allowed in general unix paths. In particular, white space is not allowed in the path lists.

There is no permission checking on the chroot jail for either execve or rerunas.

The permission allowed by fork is not clear.

AUTHOR

Network Associates. Send email to <privman@nailabs.com>

SEE ALSO

priv_bind(3) priv_daemon(3) priv_execve(3) priv_fopen(3) priv_fork(3) priv_wait4(3) priv_init(3) priv_open(3) priv_pam(3) priv_popen(3) priv_rerunas(3) priv_respawn_as(3) privman(7)
Search for    or go to Top of page |  Section 5 |  Main Index


Unix PRIVMAN_CONF (5) SEPTEMBER 2002

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.