owamp-server.conf

package: owamp-server

title: owamp-server.conf(5)

text:
# owamp-server.conf(5)

## NAME
owamp-server.conf - One-way latency daemon configuration file.

## DESCRIPTION
The owamp-server.conf file is the configuration file for the owampd(8) daemon. It is used to configure the basic operation of the server. For example, what addresses and ports it should listen on, where it should send error messages, and where it should save files.

The policy rules for owampd are configured using the owamp-server.limits file; the details for configuring those policies are described in the owamp-server.limits(5) manual page.

The format of this file is:

- Comment lines are any line where the first non-whitespace character is '#'. These lines are counted for the purposes of returning line numbers in error messages but are otherwise ignored by owampd.

- Lines may be continued using the semi-standard '\' character followed immediately by a newline character. This is the only valid place for the '\' character. If it is found elsewhere, a syntax error is reported.

- Blank lines are treated as comment lines.

- All other lines are used to set configuration options. The format of these lines is an initial keyword followed by a variable list of arguments, separated by whitespace.

## CONFIGURATION OPTIONS
authmode authmode

Specify the authentication modes the server is willing to use for communication. authmode should be set as a character string, with any or all of the characters "AEO". The modes are:

A

[A]uthenticated. This mode encrypts the control connection and encrypts part of each test packet.

E

[E]ncrypted. This mode encrypts the control connection and encrypts each test packet in full.

O

[O]pen. No encryption of any kind is done.

The server can specify all the modes with which it is willing to communicate. The most strict mode that both the server and the client are willing to use will be selected.

Default:

"AEO".

controltimeout controltimeout

Number of seconds to wait for protocol messages before timing out.

Default:

1800

datadir datadir

Directory path where data files will be placed. The data files are the "receive" session files that are buffered on the server. Policy restrictions can be used to set how much disk space a given connection can use, as well as to determine when each file is deleted. (See the owamp-server.limits(f) manual page.)

Default:

Current directory

dieby dieby

Number of seconds to wait for child processes to gracefully terminate before killing them with SIGKILL. This is in response to the master process receiving SIGTERM or SIGHUP.

This option should no longer be needed. If child processes are not exiting gracefully, please send a bug report to owamp-users@internet2.edu.

Default:

30

diskfudge diskfudge

Fudge factor to use when determining if a buffered owp file should be kept. It creates a hard limit for disk usage. The soft limit is determined by the limitclass that a connection matches [see the owamp-server.limits(5) manual page] and is applied when a test is requested. If the estimated file-size of the test would put the limitclass over the soft limit, then the test is denied. However, it is possible, due to duplicate packets, that a test session file may end up larger than this estimate. If that happens, and if the file is successfully saved to disk, then, upon completion of the test, the actual file-size is used to update the disk usage in the resource broker process. At this point, the hard limit is applied. The hard limit is determined by multiplying the soft limit by the diskfudge. If the final file-size causes the disk space used by the limitclass to be larger than the quota defined by the hard limit then the file is immediately deleted.

A liberal factor is recommended because this factor won't come in to play unless there are numerous duplicates, and that is precisely the kind of data most users will want to see. However, it is important to have this factor to ensure disk usage is not too vulnerable to replay DOS attacks of the test protocol.)

The valid values for diskfudge are 1.0-10.0.

Default:

1.0 (hard limit is the same as the soft limit)

enddelay enddelay

Amount of time for a sender to wait after session completion (last packet send-time plus timeout) before sending the stop sessions message. This is important if the sender clock is running ahead of the receiver clock.

A session is complete timeout after the send time of the final packet. If the sender clock is ahead of the receivers clock, the sender will declare the session complete before the receiver. The receiver is only allowed to retain records for the packets that were sent at least timeout before it receives the stop sessions message from the sender. Therefore, if the sender clock is running ahead of the receiver clock, the receiver will be forced to delete some number of the final packets from the session.

This parameter directs the sender to wait enddelay after session completion allowing the receiver clock to be essentially enddelay later than the sender clock and still retain full sessions.

Default:

1.0 (seconds)

facility facility

Specify the syslog facility to log messages.

Default:

LOG_DAEMON

group group

Specifies the gid the owampd process should run as. group can be specified using a valid group name on the system or by using -gid. This option is only used if owampd is started as root.

This option can be useful to limit log-file permissions to only users in this group.

loglocation

Directs the owampd process to report source code file and line number information with error messages. This is a particularly useful option to set when sending in messages as part of a bug report.

maxcontrolsessions sessions

Specifies the maximum number of control sessions that can be active concurrently. Further connections will be closed until the limit is no longer exceeded.

Default:

0 - unlimited

pbkdf2_count count

This indicates the count parameter for the pseudo-random key derivation function that is used to derive the session key from the long term key stored in the owamp-server.pfs file.

Default:

2048

rootfolly

If present, this disables the requirement that owampd run with non-root permissions. There are legitimate reasons to run owampd as root, but it is more risky. (For example, some operating systems require root permissions to set some DSCP values requested by a client.) This additional option was added to ensure root permissions are only used when explicitly intended.

srcnode nodename:port

Specify the address and port that owampd will listen for requests. nodename can be specified using a DNS name or using the textual representation of the address. It is possible to set the source address without setting the port by simply leaving off the ':' and port specification. Likewise, a non-default port can be specified for all system addresses (wildcard) by starting the specification string with a ':'. If an IPv6 address is specified, note that the accepted format contains nodename in square brackets as: [fe80::fe9f:62d8]. This ensures the port number is distinct from the address specification. The address can be wildcarded by only specifying the port portion.

Because the default port for owampd is in the protected range for most operating systems, it is usually required that owampd is stared as root. This option can be used to specify a non-standard port value that is not protected.

Default:

nodename is wildcarded as any currently available address

port is 861.

testports 0 | lowport-highport

Specify the specific port range to use on the local host for OWAMP-Test packets. This can be specified in two ways. First, as 0 which would indicate owampd should allow the system to pick the port (ephemeral). Second, as a range. lowport must be a smaller value than highport and both numbers must be valid port values. (16 bit unsigned integer values)

Default:

0

user user

Specifies the uid the owampd process should run as. user can be specified using a valid user name on the system or by using -uid. This option is only used if owampd is started as root.

In the default case, owampd should be started as root so it can bind the default port 861. (See srcnode option.) owampd will release root permissions shortly after binding to this protected port and requests will be serviced by processes running with permissions defined by the user.

vardir vardir

Directory path where the owamp-server.pid and owamp-server.info files will be placed.

Default:

Current directory

verbose

If this option is present, it directs the owampd process to generate more verbose messages to syslog.

## SEE ALSO
owping(1), owampd(8), owamp-server.limits(5), owamp-server.pfs(5), pfstore(1), and the http://e2epi.internet2.edu/owamp/ web site.

## ACKNOWLEDGMENTS
This material is based in part on work supported by the National Science Foundation (NSF) under Grant No. ANI-0314723. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.


owamp-server.limits

title: owamp-server.limits(5)

text:
# owamp-server.limits(5)

## NAME
owamp-server.limits - One-way latency server policy configuration file

## DESCRIPTION
The owamp-server.limits file is used to define the policy configuration for the owampd program. It allows the system administrator to allocate the resources in a variety of ways.

There are two parts to the policy configuration:

Authentication

Who is making the request? This can be very specific to an individual user or it can be more general in that the connection is coming from some particular network.

Authorization

Now that the connection has been generally identified, what will owampd allow it to do?

The authentication is done by assigning a limitclass to each new connection as it comes in. Each limitclass has a set of limits associated with it. The limitclasses are hierarchical, so a connection must pass the limit restrictions of the given limitclass as well as all parent classes.

Within the owamp-server.limits file, assign lines are used to assign a limitclass to a given connection. limit lines are used to define a limitclass and set the limits associated with that limitclass. The file is read sequentially, and it is not permitted to use a limitclass before it is defined using a limit line.

The format of this file is:

- Comment lines are any line where the first non-whitespace character is '#'. These lines are counted to return line numbers in error messages but are otherwise ignored by owampd.

- Lines may be continued using the semi-standard '\' character followed immediately by a newline. This is the only valid place for the '\' character. If it is found elsewhere a syntax error is reported.

- Blank lines are treated as comment lines.

- All other lines must conform to the syntax of a limit line or an assign line.

## CONFIGURATION OPTIONS
limit

This directive is used to define the limitclass hierarchy. It defines the limitclassname as well as the limits associated with that class. A limitclassname may only be defined once. The format of the limit directive is:

limit limitclassname with limtype=value[,limtype=value]* limitclassname defines the name of the class with the given limits. Whitespace is used as a separator but is otherwise ignored. limitclassname may be used as a directory name component within owampd, so take care not to use characters that would be invalid. (i.e. '*' or '/' would be particularly bad.)

limtype and value indicate the particular type of limit and value to apply to this limitclass. The available settings for limtype are:

limtype

valid values

default

allow_open_mode

on/off

on

bandwidth

integer (bits/sec)

0 (unlimited)

disk

integer (bytes)

0 (unlimited)

delete_on_fetch

on/off

off

parent

already defined limitclassname

null

test_sessions

integer sessions

0 (unlimited)

allow_open_mode

This limit is only useful if the class is assigned to a netmask. It is used to limit specific IP/netmask identities to only encrypted or authenticated mode transactions or to allow open mode.

bandwidth

Maximum amount of bandwidth to allow limitclass to use concurrently in all one-way tests. 0 indicates unlimited by policy, but remember this is checked all the way to the root of the hierarchy. (If you want an unlimited limitclass, your root must be unlimited as well as the whole path down to the given limitclass.)

disk

Maximum amount of disk space to allow a given limitclass to consume. This defines a limit that is used during the authorization of a given test request (this is a soft limit). If the estimated file size for a test request is larger than the disk limit, the test request will be denied. Additionally, because a given test can actually consume more space than this estimate due to duplicate packets, the diskfudge factor is used upon the completion of a test to decide if the file should be kept. If the new file causes the disk space used by a limitclass to be larger than the disk limit multiplied by the diskfudge factor (this defines the hard limit) the file will be deleted.

delete_on_fetch

Indicates that buffered data files should be automatically be deleted by the owampd server as soon as they are fetched.

test_sessions

This limits the number of test sessions that can be requested per control session. 0 indicates unlimited by policy, but remember this is checked all the way to the root of the hierarchy. (If you want an unlimited class, your root must be unlimited, and the whole path down to the given class.)

parent

The first limit line cannot have a parent since none have been defined yet. As such, the first line defines the root of your class hierarchy. All remaining limit lines MUST assign a parent. (It is hierarchical, after all.)

assign

The assign directive is used to assign a limitclass to a given connection. Basically, it authenticates the connection. The format of the assign directive is:

assign authtype [args] limitclassname authtype identifies the type of authentication being used. Whitespace is used as a separator but is otherwise ignored. limitclassname must have been previously defined with the limit directive earlier in the file.

The available settings for authtype are:

default

Used if no other assignment matches. It takes no args.

net subnet

Assign a specific subnet to a given limitclass. subnet must be specified using VLSM notation (IP/nbits). The only arg is the subnet. For example:

127.0.0.1/32

would match only the loopback IPv4 address.

::1/128

would match only the loopback IPv6 address.

192.168.1.0/24

would match all hosts on the 192.168.1.XXX network.

There must be no set bits in the non-masked portion of the address part of the subnet specification. i.e., 192.168.1.1/24 would be an invalid subnet due to the bit set in the fourth octet.

user user

Assign a specific user to a given limitclass. The user must be defined in the owamp-server.pfs file.

## AUTHENTICATION PROCESS
owampd determines if it should allow a connection from the client based upon the authentication mode of the request and the source IP address of the connection. If the client connection is in authenticated or encrypted mode, the daemon does not do any filtering based upon the source address of the connection. (See the authmode option in owamp-server.conf.) In these modes owampd simply uses the identity of the connection to determine the limitclass limits. If the connection is made in open mode, then owampd first uses the source address to determine if owampd should allow an open mode connection from that subnet at all. (This is the purpose of the allow_open_mode limtype described above.) If open mode is allowed from this subnet, then the limitclass is determined by the closest subnet match defined by the assign net lines in the owamp-server.limits file.

## EXAMPLES
An initial limit line might look like:

limit root with \

bandwidth=900m, \

disk=2g, \

allow_open_mode=off

This would create a limitclass named root. Because no parent is specified, this must be the first limitclass defined in the file. This limitclass has very liberal limits (900m limit on bandwidth, and 2 GB of disk space). However, open mode authentication is not enabled for this limitclass, so the connections that get these limits must successfully authenticate using an AES key derived from the pass-phrase in the owamp-server.pfs file.

If an administrator also wants to create a limitclass that is used to deny all requests, they might add:

limit jail with \

parent=root, \

bandwidth=1, \

disk=1, \

allow_open_mode=off

This would create a limitclass named jail. Because the limits for bandwidth and disk are so low, virtually all tests will be denied. allow_open_mode is off, so initial connections that are not in authenticated or encrypted mode will be dropped immediately. (It would not make much sense to assign a user identity to this limitclass. If you don't want connections from a particular user identity the best thing to do is to remove that user from the owamp-server.pfs file.)

If the administrator wanted to allow a limited amount of open tests, they could define a limitclass like:

limit open with \

parent=root, \

bandwidth=10k, \

disk=10m, \

allow_open_mode=on

This could be used to allow testing by random connections. It limits those tests to 10 kilobits of bandwidth and 10 Mbytes of buffer space.

Now, these three limitclasses might be assigned to specific connections in the following ways:

\# default open

assign default open

\# badguys subnet

assign net 192.168.1.0/24 jail

\# network admins

assign user joe root

assign user jim root

assign user bob root

This set of assign lines specifically denies access from any open mode connection from the badguys subnet. It specifically allows access to authenticated or encrypted mode transactions that can authenticate as the identities joe jim or bob (even from the badguys subnet). All other connections would match the assign default rule and get the limits associated with the open limitclass.

## SEE ALSO
owping(1), owampd(8), owamp-server.limits(5), owamp-server.pfs(5), pfstore(1), and the http://e2epi.internet2.edu/owamp/ web site.

## ACKNOWLEDGMENTS
This material is based in part on work supported by the National Science Foundation (NSF) under Grant No. ANI-0314723. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.


owamp-server.pfs

title: owamp-server.pfs(5)

text:
# owamp-server.pfs(5)

## NAME
owamp-server.pfs - One-way latency server pass-phrase store

## DESCRIPTION
The owamp-server.pfs file (owamp-server.pfs by default) is used to hold the identity/pass-phrase pairs needed for owampd to authenticate users. The format of this file is described in the pfstore(1) manual page. The location of this file is controlled by the -c option to owampd.

owampd uses symmetric AES keys for authentication. These keys are derived from a shared secret (the pass-phrase) using the PBKDF2 algorithm (RFC 2898) with an HMAC-SHA1 as the pseudorandom function.

Therefore, the owping client must have access to the exact same pass-phrase that the owampd server uses. Both the client and the server need to derive the same AES key for authentication to work. It is important that the system administrator and end user ensure the pass-phrase is not compromised.

If the owping client is able to authenticate using the identity and derived AES key, owampd will use the directives found in the owamp-server.limits file to map policy restrictions for this connection.

## SECURITY CONSIDERATIONS
The pass-phrases in the owamp-server.pfs file are not encrypted in any way. (They are simply hex encoded.) The security of these pass-phrases are completely dependent upon the security of the filesystem and the discretion of the system administrator.

## RESTRICTIONS
Identity names are restricted to 80 characters.

## SEE ALSO
pfstore(1), owping(1), owampd(8), owamp-server.limits(5), and the http://e2epi.internet2.edu/owamp/ web site.

## ACKNOWLEDGMENTS
This material is based in part on work supported by the National Science Foundation (NSF) under Grant No. ANI-0314723. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.


twamp-server.conf

title: twamp-server.conf(5)

text:
# twamp-server.conf(5)

## NAME
twamp-server.conf - Two-way active measurement daemon configuration file.

## DESCRIPTION
The twamp-server.conf file is the configuration file for the twampd(8) daemon. It is used to configure the basic operation of the server. For example, what addresses and ports it should listen on, where it should send error messages, and where it should save files.

The policy rules for twampd are configured using the twamp-server.limits file; the details for configuring those policies are described in the twamp-server.limits(5) manual page.

The format of this file is:

- Comment lines are any line where the first non-whitespace character is '#'. These lines are counted for the purposes of returning line numbers in error messages but are otherwise ignored by twampd.

- Lines may be continued using the semi-standard '\' character followed immediately by a newline character. This is the only valid place for the '\' character. If it is found elsewhere, a syntax error is reported.

- Blank lines are treated as comment lines.

- All other lines are used to set configuration options. The format of these lines is an initial keyword followed by a variable list of arguments, separated by whitespace.

## CONFIGURATION OPTIONS
authmode authmode

Specify the authentication modes the server is willing to use for communication. authmode should be set as a character string, with any or all of the characters "AEO". The modes are:

A

[A]uthenticated. This mode encrypts the control connection and encrypts part of each test packet.

E

[E]ncrypted. This mode encrypts the control connection and encrypts each test packet in full.

O

[O]pen. No encryption of any kind is done.

The server can specify all the modes with which it is willing to communicate. The most strict mode that both the server and the client are willing to use will be selected.

Default:

"AEO".

controltimeout controltimeout

Number of seconds to wait for protocol messages before timing out.

Default:

900

datadir datadir

Directory path where data files will be placed. The data files are the "receive" session files that are buffered on the server. Policy restrictions can be used to set how much disk space a given connection can use, as well as to determine when each file is deleted. (See the twamp-server.limits(f) manual page.)

Default:

Current directory

dieby dieby

Number of seconds to wait for child processes to gracefully terminate before killing them with SIGKILL. This is in response to the master process receiving SIGTERM or SIGHUP.

This option should no longer be needed. If child processes are not exiting gracefully, please send a bug report to owamp-users@internet2.edu.

Default:

30

diskfudge diskfudge

Fudge factor to use when determining if a buffered owp file should be kept. It creates a hard limit for disk usage. The soft limit is determined by the limitclass that a connection matches [see the twamp-server.limits(5) manual page] and is applied when a test is requested. If the estimated file-size of the test would put the limitclass over the soft limit, then the test is denied. However, it is possible, due to duplicate packets, that a test session file may end up larger than this estimate. If that happens, and if the file is successfully saved to disk, then, upon completion of the test, the actual file-size is used to update the disk usage in the resource broker process. At this point, the hard limit is applied. The hard limit is determined by multiplying the soft limit by the diskfudge. If the final file-size causes the disk space used by the limitclass to be larger than the quota defined by the hard limit then the file is immediately deleted.

A liberal factor is recommended because this factor won't come in to play unless there are numerous duplicates, and that is precisely the kind of data most users will want to see. However, it is important to have this factor to ensure disk usage is not too vulnerable to replay DOS attacks of the test protocol.)

The valid values for diskfudge are 1.0-10.0.

Default:

1.0 (hard limit is the same as the soft limit)

enddelay enddelay

Amount of time for a sender to wait after session completion (last packet send-time plus timeout) before sending the stop sessions message. This is important if the sender clock is running ahead of the receiver clock.

A session is complete timeout after the send time of the final packet. If the sender clock is ahead of the receivers clock, the sender will declare the session complete before the receiver. The receiver is only allowed to retain records for the packets that were sent at least timeout before it receives the stop sessions message from the sender. Therefore, if the sender clock is running ahead of the receiver clock, the receiver will be forced to delete some number of the final packets from the session.

This parameter directs the sender to wait enddelay after session completion allowing the receiver clock to be essentially enddelay later than the sender clock and still retain full sessions.

Default:

1.0 (seconds)

facility facility

Specify the syslog facility to log messages.

Default:

LOG_DAEMON

group group

Specifies the gid the twampd process should run as. group can be specified using a valid group name on the system or by using -gid. This option is only used if twampd is started as root.

This option can be useful to limit log-file permissions to only users in this group.

loglocation

Directs the twampd process to report source code file and line number information with error messages. This is a particularly useful option to set when sending in messages as part of a bug report.

maxcontrolsessions sessions

Specifies the maximum number of control sessions that can be active concurrently. Further connections will be closed until the limit is no longer exceeded.

Default:

0 - unlimited

pbkdf2_count count

This indicates the count parameter for the pseudo-random key derivation function that is used to derive the session key from the long term key stored in the twamp-server.pfs file.

Default:

2048

rootfolly

If present, this disables the requirement that twampd run with non-root permissions. There are legitimate reasons to run twampd as root, but it is more risky. (For example, some operating systems require root permissions to set some DSCP values requested by a client.) This additional option was added to ensure root permissions are only used when explicitly intended.

srcnode nodename:port

Specify the address and port that twampd will listen for requests. nodename can be specified using a DNS name or using the textual representation of the address. It is possible to set the source address without setting the port by simply leaving off the ':' and port specification. Likewise, a non-default port can be specified for all system addresses (wildcard) by starting the specification string with a ':'. If an IPv6 address is specified, note that the accepted format contains nodename in square brackets as: [fe80::fe9f:62d8]. This ensures the port number is distinct from the address specification. The address can be wildcarded by only specifying the port portion.

Because the default port for twampd is in the protected range for most operating systems, it is usually required that twampd is stared as root. This option can be used to specify a non-standard port value that is not protected.

Default:

nodename is wildcarded as any currently available address

port is 862.

testports 0 | lowport-highport

Specify the specific port range to use on the local host for TWAMP-Test packets. This can be specified in two ways. First, as 0 which would indicate twampd should allow the system to pick the port (ephemeral). Second, as a range. lowport must be a smaller value than highport and both numbers must be valid port values. (16 bit unsigned integer values)

Default:

0

testtimeout testtimeout

Number of seconds to wait for test packets before timing the test session out.

Default:

900

user user

Specifies the uid the twampd process should run as. user can be specified using a valid user name on the system or by using -uid. This option is only used if twampd is started as root.

In the default case, twampd should be started as root so it can bind the default port 862. (See srcnode option.) twampd will release root permissions shortly after binding to this protected port and requests will be serviced by processes running with permissions defined by the user.

vardir vardir

Directory path where the twamp-server.pid and twamp-server.info files will be placed.

Default:

Current directory

verbose

If this option is present, it directs the twampd process to generate more verbose messages to syslog.

## SEE ALSO
twping(1), twampd(8), twamp-server.limits(5), twamp-server.pfs(5), pfstore(1), and the http://e2epi.internet2.edu/owamp/ web site.

## ACKNOWLEDGMENTS
This material is based in part on work supported by the National Science Foundation (NSF) under Grant No. ANI-0314723. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.


twamp-server.limits

title: twamp-server.limits(5)

text:
# twamp-server.limits(5)

## NAME
twamp-server.limits - Two-way active measurement server policy configuration file

## DESCRIPTION
The twamp-server.limits file is used to define the policy configuration for the twampd program. It allows the system administrator to allocate the resources in a variety of ways.

There are two parts to the policy configuration:

Authentication

Who is making the request? This can be very specific to an individual user or it can be more general in that the connection is coming from some particular network.

Authorization

Now that the connection has been generally identified, what will twampd allow it to do?

The authentication is done by assigning a limitclass to each new connection as it comes in. Each limitclass has a set of limits associated with it. The limitclasses are hierarchical, so a connection must pass the limit restrictions of the given limitclass as well as all parent classes.

Within the twamp-server.limits file, assign lines are used to assign a limitclass to a given connection. limit lines are used to define a limitclass and set the limits associated with that limitclass. The file is read sequentially, and it is not permitted to use a limitclass before it is defined using a limit line.

The format of this file is:

- Comment lines are any line where the first non-whitespace character is '#'. These lines are counted to return line numbers in error messages but are otherwise ignored by twampd.

- Lines may be continued using the semi-standard '\' character followed immediately by a newline. This is the only valid place for the '\' character. If it is found elsewhere a syntax error is reported.

- Blank lines are treated as comment lines.

- All other lines must conform to the syntax of a limit line or an assign line.

## CONFIGURATION OPTIONS
limit

This directive is used to define the limitclass hierarchy. It defines the limitclassname as well as the limits associated with that class. A limitclassname may only be defined once. The format of the limit directive is:

limit limitclassname with limtype=value[,limtype=value]* limitclassname defines the name of the class with the given limits. Whitespace is used as a separator but is otherwise ignored. limitclassname may be used as a directory name component within twampd, so take care not to use characters that would be invalid. (i.e. '*' or '/' would be particularly bad.)

limtype and value indicate the particular type of limit and value to apply to this limitclass. The available settings for limtype are:

limtype

valid values

default

allow_open_mode

on/off

on

bandwidth

integer (bits/sec)

0 (unlimited)

disk

integer (bytes)

0 (unlimited)

delete_on_fetch

on/off

off

parent

already defined limitclassname

null

test_sessions

integer sessions

0 (unlimited)

allow_open_mode

This limit is only useful if the class is assigned to a netmask. It is used to limit specific IP/netmask identities to only encrypted or authenticated mode transactions or to allow open mode.

bandwidth

Maximum amount of bandwidth to allow limitclass to use concurrently in all one-way tests. 0 indicates unlimited by policy, but remember this is checked all the way to the root of the hierarchy. (If you want an unlimited limitclass, your root must be unlimited as well as the whole path down to the given limitclass.)

disk

Maximum amount of disk space to allow a given limitclass to consume. This defines a limit that is used during the authorization of a given test request (this is a soft limit). If the estimated file size for a test request is larger than the disk limit, the test request will be denied. Additionally, because a given test can actually consume more space than this estimate due to duplicate packets, the diskfudge factor is used upon the completion of a test to decide if the file should be kept. If the new file causes the disk space used by a limitclass to be larger than the disk limit multiplied by the diskfudge factor (this defines the hard limit) the file will be deleted.

delete_on_fetch

Indicates that buffered data files should be automatically be deleted by the twampd server as soon as they are fetched.

test_sessions

This limits the number of test sessions that can be requested per control session. 0 indicates unlimited by policy, but remember this is checked all the way to the root of the hierarchy. (If you want an unlimited class, your root must be unlimited, and the whole path down to the given class.)

parent

The first limit line cannot have a parent since none have been defined yet. As such, the first line defines the root of your class hierarchy. All remaining limit lines MUST assign a parent. (It is hierarchical, after all.)

assign

The assign directive is used to assign a limitclass to a given connection. Basically, it authenticates the connection. The format of the assign directive is:

assign authtype [args] limitclassname authtype identifies the type of authentication being used. Whitespace is used as a separator but is otherwise ignored. limitclassname must have been previously defined with the limit directive earlier in the file.

The available settings for authtype are:

default

Used if no other assignment matches. It takes no args.

net subnet

Assign a specific subnet to a given limitclass. subnet must be specified using VLSM notation (IP/nbits). The only arg is the subnet. For example:

127.0.0.1/32

would match only the loopback IPv4 address.

::1/128

would match only the loopback IPv6 address.

192.168.1.0/24

would match all hosts on the 192.168.1.XXX network.

There must be no set bits in the non-masked portion of the address part of the subnet specification. i.e., 192.168.1.1/24 would be an invalid subnet due to the bit set in the fourth octet.

user user

Assign a specific user to a given limitclass. The user must be defined in the twamp-server.pfs file.

## AUTHENTICATION PROCESS
twampd determines if it should allow a connection from the client based upon the authentication mode of the request and the source IP address of the connection. If the client connection is in authenticated or encrypted mode, the daemon does not do any filtering based upon the source address of the connection. (See the authmode option in twamp-server.conf.) In these modes twampd simply uses the identity of the connection to determine the limitclass limits. If the connection is made in open mode, then twampd first uses the source address to determine if twampd should allow an open mode connection from that subnet at all. (This is the purpose of the allow_open_mode limtype described above.) If open mode is allowed from this subnet, then the limitclass is determined by the closest subnet match defined by the assign net lines in the twamp-server.limits file.

## EXAMPLES
An initial limit line might look like:

limit root with \

bandwidth=900m, \

allow_open_mode=off

This would create a limitclass named root. Because no parent is specified, this must be the first limitclass defined in the file. This limitclass has a very liberal limit for bandwidth (900m). However, open mode authentication is not enabled for this limitclass, so the connections that get these limits must successfully authenticate using an AES key derived from the pass-phrase in the twamp-server.pfs file.

If an administrator also wants to create a limitclass that is used to deny all requests, they might add:

limit jail with \

parent=root, \

bandwidth=1, \

allow_open_mode=off

This would create a limitclass named jail. Because the limit for bandwidth is so low, virtually all tests will be denied. allow_open_mode is off, so initial connections that are not in authenticated or encrypted mode will be dropped immediately. (It would not make much sense to assign a user identity to this limitclass. If you don't want connections from a particular user identity the best thing to do is to remove that user from the twamp-server.pfs file.)

If the administrator wanted to allow a limited amount of open tests, they could define a limitclass like:

limit open with \

parent=root, \

bandwidth=10k, \

allow_open_mode=on

This could be used to allow testing by random connections. It limits those tests to 10 kilobits of bandwidth.

Now, these three limitclasses might be assigned to specific connections in the following ways:

\# default open

assign default open

\# badguys subnet

assign net 192.168.1.0/24 jail

\# network admins

assign user joe root

assign user jim root

assign user bob root

This set of assign lines specifically denies access from any open mode connection from the badguys subnet. It specifically allows access to authenticated or encrypted mode transactions that can authenticate as the identities joe jim or bob (even from the badguys subnet). All other connections would match the assign default rule and get the limits associated with the open limitclass.

## SEE ALSO
twping(1), twampd(8), twamp-server.limits(5), twamp-server.pfs(5), pfstore(1), and the http://e2epi.internet2.edu/owamp/ web site.

## ACKNOWLEDGMENTS
This material is based in part on work supported by the National Science Foundation (NSF) under Grant No. ANI-0314723. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.


twamp-server.pfs

title: twamp-server.pfs(5)

text:
# twamp-server.pfs(5)

## NAME
twamp-server.pfs - One-way latency server pass-phrase store

## DESCRIPTION
The twamp-server.pfs file is used to hold the identity/pass-phrase pairs needed for twampd to authenticate users. The format of this file is described in the pfstore(1) manual page. The location of this file is controlled by the -c option to twampd.

twampd uses symmetric AES keys for authentication. These keys are derived from a shared secret (the pass-phrase) using the PBKDF2 algorithm (RFC 2898) with an HMAC-SHA1 as the pseudorandom function.

Therefore, the twping client must have access to the exact same pass-phrase that the twampd server uses. Both the client and the server need to derive the same AES key for authentication to work. It is important that the system administrator and end user ensure the pass-phrase is not compromised.

If the twping client is able to authenticate using the identity and derived AES key, twampd will use the directives found in the twamp-server.limits file to map policy restrictions for this connection.

## SECURITY CONSIDERATIONS
The pass-phrases in the twamp-server.pfs file are not encrypted in any way. (They are simply hex encoded.) The security of these pass-phrases are completely dependent upon the security of the filesystem and the discretion of the system administrator.

## RESTRICTIONS
Identity names are restricted to 80 characters.

## SEE ALSO
pfstore(1), twping(1), twampd(8), twamp-server.limits(5), and the http://e2epi.internet2.edu/owamp/ web site.

## ACKNOWLEDGMENTS
This material is based in part on work supported by the National Science Foundation (NSF) under Grant No. ANI-0314723. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.


owfs

package: owfs-man

title: owfs(5)

summary: owfs programs configuration file

text:
# owfs(5)

## NAME
owfs.conf - owfs programs configuration file

## SYNOPSIS
An OWFS configuration file is specified on the command line:

owfs -c config_file [other options]

The file name is arbitrary, there is no default configuration file used.

## USAGE
A configuration file can be invoked for any of the OWFS programs ( owfs (1) owhttpd (1) owserver (1) owftpd (1) ) or any of the language bindings ( owperl (1) owcapi (1) owtcl (1) owphp owpython ) to set command line parameters.

## SYNTAX
Similar to Unix shell script or perl syntax

Comments

\# Any # marks the start of a comment

\# blank lines are ignored

Options

option # some options (like 'foreground') take no values

option = value # other options need a value

option value # '=' can be omitted if whitespace separates

Option # Case is ignored (for options, not values)

opt # non-ambiguous abbreviation allowed

-opt --opt # hyphens ignored

owserver

server: opt = value # only owserver effected by this line

! server: opt = value # owserver NOT effected by this line

owhttpd

http: opt = value # only owhttpd effected by this line

! http: opt = value # owhttpd NOT effected by this line

owftpd

ftp: opt = value # only owftpd effected by this line

! ftp: opt = value # owftpd NOT effected by this line

owfs

owfs: opt = value # only owfs effected by this line

! owfs: opt = value # owfs NOT effected by this line

Limits

\# maximum line length of 250 characters

\# no limit on number of lines

## DESCRIPTION

### 1-Wire
1-wire is a wiring protocol and series of devices designed and manufactured by Dallas Semiconductor, Inc. The bus is a low-power low-speed low-connector scheme where the data line can also provide power.

Each device is uniquely and unalterably numbered during manufacture. There are a wide variety of devices, including memory, sensors (humidity, temperature, voltage, contact, current), switches, timers and data loggers. More complex devices (like thermocouple sensors) can be built with these basic devices. There are also 1-wire devices that have encryption included.

The 1-wire scheme uses a single bus master and multiple slaves on the same wire. The bus master initiates all communication. The slaves can be individually discovered and addressed using their unique ID.

Bus masters come in a variety of configurations including serial, parallel, i2c, network or USB adapters.

### OWFS design
OWFS is a suite of programs that designed to make the 1-wire bus and its devices easily accessible. The underlying principle is to create a virtual filesystem, with the unique ID being the directory, and the individual properties of the device are represented as simple files that can be read and written.

Details of the individual slave or master design are hidden behind a consistent interface. The goal is to provide an easy set of tools for a software designer to create monitoring or control applications. There are some performance enhancements in the implementation, including data caching, parallel access to bus masters, and aggregation of device communication. Still the fundemental goal has been ease of use, flexibility and correctness rather than speed.

### Configuration
owfs.conf (5) allows a uniform set of command line parameters to be set.

Not all OWFS programs use the same command line options, but the non-relevant ones will be ignored.

Command line and configuration options can mixed. They will be invoked in the order presented. Left to right for the command line. Top to bottom for the configuration file.

Configuration files can call other configuration files. There is an arbitrary depth of 5 levels to prevent infinite loops. More than one configuration file can be specified.

## SAMPLE
Here is a sample configuration file with all the possible parameters included.

\# Sources

device = /dev/ttyS0 # serial port: DS9097U DS9097 ECLO or LINK

device = /dev/i2c-0 # i2c port: DS2482-100 or DS2482-800

usb # USB device: DS9490 PuceBaboon

usb = 2 # Second DS9490

usb = all # All DS9490s

altUSB # Willy Robison's tweaks

LINK = /dev/ttyS0 # serial LINK in ascii mode

LINK = [address:]port # LINK-HUB-E (tcp access)

HA7 # HA7Net autodiscovery mode

HA7 = address[:port] # HA7Net at tcp address (port 80)

etherweather = address[:port] # Etherweather device

server = [address:]port # owserver tcp address

FAKE = 10,1B # Random simulated device with family codes (hex)

TESTER = 28,3E # Predictable simulated device with family codes

\#

\# Sinks

\# # owfs specific

mountpoint = filelocation # FUSE mount point

allow_other # Short hand for FUSE mount option "

\# # owhttpd owserver owftpd specific

port = [address:]port # tcp out port

\#

\# Temperature scales

Celsius # default

Fahrenheit

Kelvin

Rankine

\#

\# Timeouts (all in seconds)

\# cache for values that change on their own

timeout_volatile = value # seconds "volatile" values remain in cache

\# cache for values that change on command

timeout_stable = value # seconds "stable" values remain in cache

\# cache for directory lists (non-alarm)

timeout_directory = value # seconds "directory" values remain in cache

\# cache for 1-wire device location

timeout_presence = value # seconds "device presence" (which bus)

timeout_serial = value # seconds to wait for serial response

timeout_usb = value # seconds to wait for USB response

timeout_network = value # seconds to wait for tcp/ip response

timeout_ftp = value # seconds inactivity before closing ftp session

\#

\# Process control

configuration = filename # file (like this) of program options

pid_file = filename # file to store PID number

foreground

background # default

readonly # prevent changing 1-wire device contents

write # default

error_print = 0-3 # 0-mixed 1-syslog 2-stderr 3-suppressed

error_level = 0-9 # increasing noise

\#

\# zeroconf / Bonjour

zero # turn on zeroconf announcement (default)

nozero # turn off zeroconf announcement

annouce = name # name of announced service (optional)

autoserver # Add owservers descovered by zeroconf/Bonjour

noautoserver # Don't use zeroconf/Bonjour owservers (default)

\#

\# tcp persistence

timeout_persistent_low = 600 # minimum time a persistent socket will stay open

timeout_persistent_high = 3600 # max time an idle client socket will stay around

\#

\# Display

format = f[.]i[[.]c] # 1-wire address f amily i d code c rc

\#

\# Cache

cache_size = 1000000 # maximum cache size (in bytes) or 0 for no limit (default 0) #

\# Information

\# (silly in a configuration file)

version

help

morehelp

## SEE ALSO

### Programs
owfs (1) owhttpd (1) owftpd (1) owserver (1) owdir (1) owread (1) owwrite (1) owpresent (1) owtap (1)

### Configuration and testing
owfs (5) owtap (1) owmon (1)

### Language bindings
owtcl (3) owperl (3) owcapi (3)

### Clocks
DS1427 (3) DS1904(3) DS1994 (3) DS2404 (3) DS2404S (3) DS2415 (3) DS2417 (3)

### ID
DS2401 (3) DS2411 (3) DS1990A (3)

### Memory
DS1982 (3) DS1985 (3) DS1986 (3) DS1991 (3) DS1992 (3) DS1993 (3) DS1995 (3) DS1996 (3) DS2430A (3) DS2431 (3) DS2433 (3) DS2502 (3) DS2506 (3) DS28E04 (3) DS28EC20 (3)

### Switches
DS2405 (3) DS2406 (3) DS2408 (3) DS2409 (3) DS2413 (3) DS28EA00 (3)

### Temperature
DS1822 (3) DS1825 (3) DS1820 (3) DS18B20 (3) DS18S20 (3) DS1920 (3) DS1921 (3) DS1821 (3) DS28EA00 (3) DS28E04 (3)

### Humidity
DS1922 (3)

### Voltage
DS2450 (3)

### Resistance
DS2890 (3)

### Multifunction (current, voltage, temperature)
DS2436 (3) DS2437 (3) DS2438 (3) DS2751 (3) DS2755 (3) DS2756 (3) DS2760 (3) DS2770 (3) DS2780 (3) DS2781 (3) DS2788 (3) DS2784 (3)

### Counter
DS2423 (3)

### LCD Screen
LCD (3) DS2408 (3)

### Crypto
DS1977 (3)

### Pressure
DS2406 (3) -- TAI8570

## AVAILABILITY
http://www.owfs.org

## AUTHOR
Paul Alfille (paul.alfille@gmail.com)


access.conf

package: pam

title: access.conf(5)

summary: the login access control table file

text:
# access.conf(5)

## NAME
access.conf - the login access control table file

## DESCRIPTION
The /etc/security/access.conf file specifies (user/group, host), (user/group, network/netmask), (user/group, tty), (user/group, X-$DISPLAY-value), or (user/group, pam-service-name) combinations for which a login will be either accepted or refused.

When someone logs in, the file access.conf is scanned for the first entry that matches the (user/group, host) or (user/group, network/netmask) combination, or, in case of non-networked logins, the first entry that matches the (user/group, tty) combination, or in the case of non-networked logins without a tty, the first entry that matches the (user/group, X-$DISPLAY-value) or (user/group, pam-service-name/) combination. The permissions field of that table entry determines whether the login will be accepted or refused.

Each line of the login access control table has three fields separated by a ":" character (colon):

permission:users/groups:origins

The first field, the permission field, can be either a "+" character (plus) for access granted or a "-" character (minus) for access denied.

The second field, the users/group field, should be a list of one or more login names, group names, or ALL (which always matches). To differentiate user entries from group entries, group entries should be written with brackets, e.g. (group).

The third field, the origins field, should be a list of one or more tty names (for non-networked logins), X $DISPLAY values or PAM service names (for non-networked logins without a tty), host names, domain names (begin with "."), host addresses, internet network numbers (end with "."), internet network addresses with network mask (where network mask can be a decimal number or an internet address also), ALL (which always matches) or LOCAL. The LOCAL keyword matches if and only if pam_get_item(3), when called with an item_type of PAM_RHOST, returns NULL or an empty string (and therefore the origins field is compared against the return value of pam_get_item(3) called with an item_type of PAM_TTY or, absent that, PAM_SERVICE).

If supported by the system you can use @netgroupname in host or user patterns. The @@netgroupname syntax is supported in the user pattern only and it makes the local system hostname to be passed to the netgroup match call in addition to the user name. This might not work correctly on some libc implementations causing the match to always fail.

The EXCEPT operator makes it possible to write very compact rules.

If the nodefgroup is not set, the group file is searched when a name does not match that of the logged-in user. Only groups are matched in which users are explicitly listed. However the PAM module does not look at the primary group id of a user.

The "#" character at start of line (no space at front) can be used to mark this line as a comment line.

## EXAMPLES
These are some example lines which might be specified in /etc/security/access.conf.

User root should be allowed to get access via cron, X11 terminal :0, tty1, ..., tty5, tty6.

+:root:crond :0 tty1 tty2 tty3 tty4 tty5 tty6

User root should be allowed to get access from hosts which own the IPv4 addresses. This does not mean that the connection have to be a IPv4 one, a IPv6 connection from a host with one of this IPv4 addresses does work, too.

+:root:192.168.200.1 192.168.200.4 192.168.200.9

+:root:127.0.0.1

User root should get access from network 192.168.201. where the term will be evaluated by string matching. But it might be better to use network/netmask instead. The same meaning of 192.168.201. is 192.168.201.0/24 or 192.168.201.0/255.255.255.0.

+:root:192.168.201.

User root should be able to have access from hosts foo1.bar.org and foo2.bar.org (uses string matching also).

+:root:foo1.bar.org foo2.bar.org

User root should be able to have access from domain foo.bar.org (uses string matching also).

+:root:.foo.bar.org

User root should be denied to get access from all other sources.

-:root:ALL

User foo and members of netgroup admins should be allowed to get access from all sources. This will only work if netgroup service is available.

+:@admins foo:ALL

User john and foo should get access from IPv6 host address.

+:john foo:2001:db8:0:101::1

User john and foo should get access from IPv6 link local host address.

+:john foo:fe80::de95:818c:1b55:7e42%eth1

User john should get access from IPv6 net/mask.

+:john:2001:db8:0:101::/64

Members of group wheel should be allowed to get access from all sources.

+:(wheel):ALL

Disallow console logins to all but the shutdown, sync and all other accounts, which are a member of the wheel group.

-:ALL EXCEPT (wheel) shutdown sync:LOCAL

All other users should be denied to get access from all sources.

-:ALL:ALL

## NOTES
The default separators of list items in a field are space, ',', and tabulator characters. Thus conveniently if spaces are put at the beginning and the end of the fields they are ignored. However if the list separator is changed with the listsep option, the spaces will become part of the actual item and the line will be most probably ignored. For this reason, it is not recommended to put spaces around the ':' characters.

An IPv6 link local host address must contain the interface identifier. IPv6 link local network/netmask is not supported.

## SEE ALSO
pam_access(8), pam.d(5), pam(8)

## AUTHORS
Original login.access(5) manual was provided by Guido van Rooij which was renamed to access.conf(5) to reflect relation to default config file.

Network address / netmask description and example text was introduced by Mike Becher <mike.becher@lrz-muenchen.de>.


faillock.conf

title: faillock.conf(5)

summary: pam_faillock configuration file

text:
# faillock.conf(5)

## NAME
faillock.conf - pam_faillock configuration file

## DESCRIPTION
faillock.conf provides a way to configure the default settings for locking the user after multiple failed authentication attempts. This file is read by the pam_faillock module and is the preferred method over configuring pam_faillock directly.

The file has a very simple name = value format with possible comments starting with # character. The whitespace at the beginning of line, end of line, and around the = sign is ignored.

## OPTIONS
dir=/path/to/tally-directory

The directory where the user files with the failure records are kept. The default is /var/run/faillock. Note: These files will disappear after reboot on systems configured with directory /var/run/faillock mounted on virtual memory.

audit

Will log the user name into the system log if the user is not found.

silent

Don't print informative messages to the user. Please note that when this option is not used there will be difference in the authentication behavior for users which exist on the system and non-existing users.

no_log_info

Don't log informative messages via syslog(3).

local_users_only

Only track failed user authentications attempts for local users in /etc/passwd and ignore centralized (AD, IdM, LDAP, etc.) users. The faillock(8) command will also no longer track user failed authentication attempts. Enabling this option will prevent a double-lockout scenario where a user is locked out locally and in the centralized mechanism.

nodelay

Don't enforce a delay after authentication failures.

deny=n

Deny access if the number of consecutive authentication failures for this user during the recent interval exceeds n. The default is 3.

fail_interval=n

The length of the interval during which the consecutive authentication failures must happen for the user account lock out is n seconds. The default is 900 (15 minutes).

unlock_time=n

The access will be re-enabled after n seconds after the lock out. The value 0 has the same meaning as value never - the access will not be re-enabled without resetting the faillock entries by the faillock(8) command. The default is 600 (10 minutes). Note that the default directory that pam_faillock uses is usually cleared on system boot so the access will be also re-enabled after system reboot. If that is undesirable a different tally directory must be set with the dir option.

Also note that it is usually undesirable to permanently lock out users as they can become easily a target of denial of service attack unless the usernames are random and kept secret to potential attackers.

even_deny_root

Root account can become locked as well as regular accounts.

root_unlock_time=n

This option implies even_deny_root option. Allow access after n seconds to root account after the account is locked. In case the option is not specified the value is the same as of the unlock_time option.

admin_group=name

If a group name is specified with this option, members of the group will be handled by this module the same as the root account (the options even_deny_root and root_unlock_time will apply to them. By default the option is not set.

## EXAMPLES
/etc/security/faillock.conf file example:

```
deny=4
unlock_time=1200
silent

```

## FILES
/etc/security/faillock.conf

the config file for custom options

## SEE ALSO
faillock(8), pam_faillock(8), pam.conf(5), pam.d(5), pam(8)

## AUTHOR
pam_faillock was written by Tomas Mraz. The support for faillock.conf was written by Brian Ward.


group.conf

title: group.conf(5)

text:
# group.conf(5)

## NAME
group.conf - configuration file for the pam_group module

## DESCRIPTION
The pam_group PAM module does not authenticate the user, but instead it grants group memberships (in the credential setting phase of the authentication module) to the user. Such memberships are based on the service they are applying for.

For this module to function correctly there must be a correctly formatted /etc/security/group.conf file present. White spaces are ignored and lines maybe extended with '\' (escaped newlines). Text following a '#' is ignored to the end of the line.

The syntax of the lines is as follows:

services;ttys;users;times;groups

The first field, the services field, is a logic list of PAM service names that the rule applies to.

The second field, the tty field, is a logic list of terminal names that this rule applies to.

The third field, the users field, is a logic list of users, or a UNIX group, or a netgroup of users to whom this rule applies. Group names are preceded by a '%' symbol, while netgroup names are preceded by a '@' symbol.

A logic list namely means individual tokens that are optionally prefixed with '!' (logical not) and separated with '&' (logical and) and '|' (logical or).

For these items the simple wildcard '*' may be used only once. With UNIX groups or netgroups no wildcards or logic operators are allowed.

The times field is used to indicate "when" these groups are to be given to the user. The format here is a logic list of day/time-range entries. The days are specified by a sequence of two character entries, MoTuSa for example is Monday Tuesday and Saturday. Note that repeated days are unset MoMo = no day, and MoWk = all weekdays bar Monday. The two character combinations accepted are Mo Tu We Th Fr Sa Su Wk Wd Al, the last two being week-end days and all 7 days of the week respectively. As a final example, AlFr means all days except Friday.

Each day/time-range can be prefixed with a '!' to indicate "anything but". The time-range part is two 24-hour times HHMM, separated by a hyphen, indicating the start and finish time (if the finish time is smaller than the start time it is deemed to apply on the following day).

The groups field is a comma or space separated list of groups that the user inherits membership of. These groups are added if the previous fields are satisfied by the user's request.

For a rule to be active, ALL of service+ttys+users must be satisfied by the applying process.

## EXAMPLES
These are some example lines which might be specified in /etc/security/group.conf.

Running 'xsh' on tty* (any ttyXXX device), the user 'us' is given access to the floppy (through membership of the floppy group)

```
xsh;tty*&!ttyp*;us;Al0000-2400;floppy
```

Running 'xsh' on tty* (any ttyXXX device), the users 'sword', 'pike' and 'shield' are given access to games (through membership of the floppy group) after work hours.

```
xsh; tty* ;sword|pike|shield;!Wk0900-1800;games, sound
xsh; tty* ;*;Al0900-1800;floppy

```

Any member of the group 'admin' running 'xsh' on tty*, is granted access (at any time) to the group 'plugdev'

```
xsh; tty* ;%admin;Al0000-2400;plugdev

```

## SEE ALSO
pam_group(8), pam.d(5), pam(8)

## AUTHOR
pam_group was written by Andrew G. Morgan <morgan@kernel.org>.


limits.conf

title: limits.conf(5)

text:
# limits.conf(5)

## NAME
limits.conf - configuration file for the pam_limits module

## DESCRIPTION
The pam_limits.so module applies ulimit limits, nice priority and number of simultaneous login sessions limit to user login sessions. This description of the configuration file syntax applies to the /etc/security/limits.conf file and *.conf files in the /etc/security/limits.d directory.

The syntax of the lines is as follows:

<domain> <type> <item> <value>

The fields listed above should be filled as follows:

<domain>

•a username

•a groupname, with @group syntax. This should not be confused with netgroups.

•the wildcard *, for default entry.

•the wildcard %, for maxlogins limit only, can also be used with %group syntax. If the % wildcard is used alone it is identical to using * with maxsyslogins limit. With a group specified after % it limits the total number of logins of all users that are member of the group.

•an uid range specified as <min_uid>:<max_uid>. If min_uid is omitted, the match is exact for the max_uid. If max_uid is omitted, all uids greater than or equal min_uid match.

•a gid range specified as @<min_gid>:<max_gid>. If min_gid is omitted, the match is exact for the max_gid. If max_gid is omitted, all gids greater than or equal min_gid match. For the exact match all groups including the user's supplementary groups are examined. For the range matches only the user's primary group is examined.

•a gid specified as %:<gid> applicable to maxlogins limit only. It limits the total number of logins of all users that are member of the group with the specified gid.

<type>

hard

for enforcing hard resource limits. These limits are set by the superuser and enforced by the Kernel. Users cannot raise their own requirement of system resources above such values.

soft

for enforcing soft resource limits. These limits are ones that the user can move up or down within the permitted range by any pre-existing hard limits. The values specified with this token can be thought of as default values, for normal system usage.

-

for enforcing both soft and hard resource limits together. Note, if you specify a type of '-' but neglect to supply the item and value fields then the module will never enforce any limits on the specified user/group etc. .

<item>

core

limits the core file size (KB)

data

maximum data size (KB)

fsize

maximum filesize (KB)

memlock

maximum locked-in-memory address space (KB)

nofile

maximum number of open file descriptors

rss

maximum resident set size (KB) (Ignored in Linux 2.4.30 and higher)

stack

maximum stack size (KB)

cpu

maximum CPU time (minutes)

nproc

maximum number of processes

as

address space limit (KB)

maxlogins

maximum number of logins for this user (this limit does not apply to user with uid=0)

maxsyslogins

maximum number of all logins on system; user is not allowed to log-in if total number of all user logins is greater than specified number (this limit does not apply to user with uid=0)

nonewprivs

value of 0 or 1; if set to 1 disables acquiring new privileges by invoking prctl(PR_SET_NO_NEW_PRIVS)

priority

the priority to run user process with (negative values boost process priority)

locks

maximum locked files (Linux 2.4 and higher)

sigpending

maximum number of pending signals (Linux 2.6 and higher)

msgqueue

maximum memory used by POSIX message queues (bytes) (Linux 2.6 and higher)

nice

maximum nice priority allowed to raise to (Linux 2.6.12 and higher) values: [-20,19]

rtprio

maximum realtime priority allowed for non-privileged processes (Linux 2.6.12 and higher)

All items support the values -1, unlimited or infinity indicating no limit, except for priority, nice, and nonewprivs. If nofile is to be set to one of these values, it will be set to the contents of /proc/sys/fs/nr_open instead (see setrlimit(3)).

If a hard limit or soft limit of a resource is set to a valid value, but outside of the supported range of the local system, the system may reject the new limit or unexpected behavior may occur. If the control value required is used, the module will reject the login if a limit could not be set.

In general, individual limits have priority over group limits, so if you impose no limits for admin group, but one of the members in this group have a limits line, the user will have its limits set according to this line.

Also, please note that all limit settings are set per login. They are not global, nor are they permanent; existing only for the duration of the session. One exception is the maxlogin option, this one is system wide. But there is a race, concurrent logins at the same time will not always be detect as such but only counted as one.

In the limits configuration file, the '#' character introduces a comment - after which the rest of the line is ignored.

The pam_limits module does report configuration problems found in its configuration file and errors via syslog(3).

## EXAMPLES
These are some example lines which might be specified in /etc/security/limits.conf.

```
*               soft    core            0
*               hard    nofile          512
@student        hard    nproc           20
@faculty        soft    nproc           20
@faculty        hard    nproc           50
ftp             hard    nproc           0
@student        -       maxlogins       4
@student        -       nonewprivs      1
:123            hard    cpu             5000
@500:           soft    cpu             10000
600:700         hard    locks           10

```

## SEE ALSO
pam_limits(8), pam.d(5), pam(8), getrlimit(2), getrlimit(3p)

## AUTHOR
pam_limits was initially written by Cristian Gafton <gafton@redhat.com>


namespace.conf

title: namespace.conf(5)

summary: the namespace configuration file

text:
# namespace.conf(5)

## NAME
namespace.conf - the namespace configuration file

## DESCRIPTION
The pam_namespace.so module allows setup of private namespaces with polyinstantiated directories. Directories can be polyinstantiated based on user name or, in the case of SELinux, user name, sensitivity level or complete security context. If an executable script /etc/security/namespace.init exists, it is used to initialize the namespace every time an instance directory is set up and mounted. The script receives the polyinstantiated directory path and the instance directory path as its arguments. The script is invoked with full root privileges and accessing the instance directory in this context needs to be done with caution, as it is controlled by the unprivileged user for which it has been created.

The /etc/security/namespace.conf file specifies which directories are polyinstantiated, how they are polyinstantiated, how instance directories would be named, and any users for whom polyinstantiation would not be performed.

When someone logs in, the file namespace.conf is scanned. Comments are marked by # characters. Each non comment line represents one polyinstantiated directory. The fields are separated by spaces but can be quoted by " characters also escape sequences \b, \n, and \t are recognized. The fields are as follows:

polydir instance_prefix method list_of_uids

The first field, polydir, is the absolute pathname of the directory to polyinstantiate. The special string $HOME is replaced with the user's home directory, and $USER with the username. This field cannot be blank.

The second field, instance_prefix is the string prefix used to build the pathname for the instantiation of <polydir>. The path must end in a trailing slash, or in a directory prefix used to build the full per-instance path. Depending on the polyinstantiation method it is then appended with "instance differentiation string" to generate the final instance directory path. This directory is created if it did not exist already, and is then bind mounted on the <polydir> to provide an instance of <polydir> based on the <method> column. The special string $HOME is replaced with the user's home directory, and $USER with the username. This field cannot be blank.

The third field, method, is the method used for polyinstantiation. It can take these values; "user" for polyinstantiation based on user name, "level" for polyinstantiation based on process MLS level and user name, "context" for polyinstantiation based on process security context and user name, "tmpfs" for mounting tmpfs filesystem as an instance dir, and "tmpdir" for creating temporary directory as an instance dir which is removed when the user's session is closed. Methods "context" and "level" are only available with SELinux. This field cannot be blank.

The fourth field, list_of_uids, is a comma separated list of user names for whom the polyinstantiation is not performed. If left blank, polyinstantiation will be performed for all users. If the list is preceded with a single "~" character, polyinstantiation is performed only for users in the list.

The method field can contain also following optional flags separated by : characters.

create=mode,owner,group - create the polyinstantiated directory. The mode, owner and group parameters are optional. The default for mode is determined by umask, the default owner is the user whose session is opened, the default group is the primary group of the user.

iscript=path - path to the instance directory init script. The base directory for relative paths is /etc/security/namespace.d.

noinit - instance directory init script will not be executed.

shared - the instance directories for "context" and "level" methods will not contain the user name and will be shared among all users.

mntopts=value - value of this flag is passed to the mount call when the tmpfs mount is done. It allows for example the specification of the maximum size of the tmpfs instance that is created by the mount call. In addition to options specified in the tmpfs(5) manual the nosuid, noexec, and nodev flags can be used to respectively disable setuid bit effect, disable running executables, and disable devices to be interpreted on the mounted tmpfs filesystem.

The directory where polyinstantiated instances are to be created, must exist and must have, by default, the mode of 0000. The requirement that the instance parent be of mode 0000 can be overridden with the command line option ignore_instance_parent_mode

In case of context or level polyinstantiation the SELinux context which is used for polyinstantiation is the context used for executing a new process as obtained by getexeccon. This context must be set by the calling application or pam_selinux.so module. If this context is not set the polyinstantiation will be based just on user name.

The "instance differentiation string" is <user name> for "user" method and <user name>_<raw directory context> for "context" and "level" methods. If the whole string is too long the end of it is replaced with md5sum of itself. Also when command line option gen_hash is used the whole string is replaced with md5sum of itself.

## EXAMPLES
These are some example lines which might be specified in /etc/security/namespace.conf.

```
      # The following three lines will polyinstantiate /tmp,

      # /var/tmp and user's home directories. /tmp and /var/tmp

      # will be polyinstantiated based on the security level

      # as well as user name, whereas home directory will be

      # polyinstantiated based on the full security context and user name.

      # Polyinstantiation will not be performed for user root

      # and adm for directories /tmp and /var/tmp, whereas home

      # directories will be polyinstantiated for all users.

      #

      # Note that instance directories do not have to reside inside

      # the polyinstantiated directory. In the examples below,

      # instances of /tmp will be created in /tmp-inst directory,

      # where as instances of /var/tmp and users home directories

      # will reside within the directories that are being

      # polyinstantiated.

      #

      /tmp     /tmp-inst/               level      root,adm

      /var/tmp /var/tmp/tmp-inst/   	level      root,adm

      $HOME    $HOME/$USER.inst/inst- context

```

For the <service>s you need polyinstantiation (login for example) put the following line in /etc/pam.d/<service> as the last line for session group:

session required pam_namespace.so [arguments]

This module also depends on pam_selinux.so setting the context.

## SEE ALSO
pam_namespace(8), pam.d(5), pam(8)

## AUTHORS
The namespace.conf manual page was written by Janak Desai <janak@us.ibm.com>. More features added by Tomas Mraz <tmraz@redhat.com>.


pam.conf

title: pam.conf(5)

summary: PAM configuration files

text:
# pam.conf(5)

## NAME
pam.conf, pam.d - PAM configuration files

## DESCRIPTION
When a PAM aware privilege granting application is started, it activates its attachment to the PAM-API. This activation performs a number of tasks, the most important being the reading of the configuration file(s): /etc/pam.conf. Alternatively and preferably, the configuration can be set by individual configuration files located in a pam.d directory. The presence of this directory will cause Linux-PAM to ignore /etc/pam.conf.

These files list the PAMs that will do the authentication tasks required by this service, and the appropriate behavior of the PAM-API in the event that individual PAMs fail.

The syntax of the /etc/pam.conf configuration file is as follows. The file is made up of a list of rules, each rule is typically placed on a single line, but may be extended with an escaped end of line: `\<LF>'. Comments are preceded with `#' marks and extend to the next end of line.

The format of each rule is a space separated collection of tokens, the first three being case-insensitive:

service type control module-path module-arguments

The syntax of files contained in the /etc/pam.d/ directory, are identical except for the absence of any service field. In this case, the service is the name of the file in the /etc/pam.d/ directory. This filename must be in lower case.

An important feature of PAM, is that a number of rules may be stacked to combine the services of a number of PAMs for a given authentication task.

The service is typically the familiar name of the corresponding application: login and su are good examples. The service-name, other, is reserved for giving default rules. Only lines that mention the current service (or in the absence of such, the other entries) will be associated with the given service-application.

The type is the management group that the rule corresponds to. It is used to specify which of the management groups the subsequent module is to be associated with. Valid entries are:

account

this module type performs non-authentication based account management. It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user -- 'root' login only on the console.

auth

this module type provides two aspects of authenticating the user. Firstly, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Secondly, the module can grant group membership or other privileges through its credential granting properties.

password

this module type is required for updating the authentication token associated with the user. Typically, there is one module for each 'challenge/response' based authentication (auth) type.

session

this module type is associated with doing things that need to be done for the user before/after they can be given service. Such things include the logging of information concerning the opening/closing of some data exchange with a user, mounting directories, etc.

If the type value from the list above is prepended with a - character the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system. This can be useful especially for modules which are not always installed on the system and are not required for correct authentication and authorization of the login session.

The third field, control, indicates the behavior of the PAM-API should the module fail to succeed in its authentication task. There are two types of syntax for this control field: the simple one has a single simple keyword; the more complicated one involves a square-bracketed selection of value=action pairs.

For the simple (historical) syntax valid control values are:

required

failure of such a PAM will ultimately lead to the PAM-API returning failure but only after the remaining stacked modules (for this service and type) have been invoked.

requisite

like required, however, in the case that such a module returns a failure, control is directly returned to the application or to the superior PAM stack. The return value is that associated with the first required or requisite module to fail. Note, this flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the not insignificant concerns of exposing a sensitive password in a hostile environment.

sufficient

if such a module succeeds and no prior required module has failed the PAM framework returns success to the application or to the superior PAM stack immediately without calling any further modules in the stack. A failure of a sufficient module is ignored and processing of the PAM module stack continues unaffected.

optional

the success or failure of this module is only important if it is the only module in the stack associated with this service+type.

include

include all lines of given type from the configuration file specified as an argument to this control.

substack

include all lines of given type from the configuration file specified as an argument to this control. This differs from include in that evaluation of the done and die actions in a substack does not cause skipping the rest of the complete module stack, but only of the substack. Jumps in a substack also can not make evaluation jump out of it, and the whole substack is counted as one module when the jump is done in a parent stack. The reset action will reset the state of a module stack to the state it was in as of beginning of the substack evaluation.

For the more complicated syntax valid control values have the following form:

```
      [value1=action1 value2=action2 ...]

```

Where valueN corresponds to the return code from the function invoked in the module for which the line is defined. It is selected from one of these: success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete, and default.

The last of these, default, implies 'all valueN's not mentioned explicitly. Note, the full list of PAM errors is available in /usr/include/security/_pam_types.h. The actionN can take one of the following forms:

ignore

when used with a stack of modules, the module's return status will not contribute to the return code the application obtains.

bad

this action indicates that the return code should be thought of as indicative of the module failing. If this module is the first in the stack to fail, its status value will be used for that of the whole stack. This is the default action for all return codes.

die

equivalent to bad with the side effect of terminating the module stack and PAM immediately returning to the application.

ok

this tells PAM that the administrator thinks this return code should contribute directly to the return code of the full stack of modules. In other words, if the former state of the stack would lead to a return of PAM_SUCCESS, the module's return code will override this value. Note, if the former state of the stack holds some value that is indicative of a modules failure, this 'ok' value will not be used to override that value.

done

equivalent to ok with the side effect of terminating the module stack and PAM immediately returning to the application unless there was a non-ignored module failure before.

N (an unsigned integer)

jump over the next N modules in the stack. Note that N equal to 0 is not allowed, it would be treated as ignore in such case. The side effect depends on the PAM function call: for pam_authenticate, pam_acct_mgmt, pam_chauthtok, and pam_open_session it is ignore; for pam_setcred and pam_close_session it is one of ignore, ok, or bad depending on the module's return value.

reset

clear all memory of the state of the module stack and start again with the next stacked module.

If a return code's action is not specifically defined via a valueN token, and the default value is not specified, that return code's action defaults to bad.

Each of the four keywords: required; requisite; sufficient; and optional, have an equivalent expression in terms of the [...] syntax. They are as follows:

required

[success=ok new_authtok_reqd=ok ignore=ignore default=bad]

requisite

[success=ok new_authtok_reqd=ok ignore=ignore default=die]

sufficient

[success=done new_authtok_reqd=done default=ignore]

optional

[success=ok new_authtok_reqd=ok default=ignore]

module-path is either the full filename of the PAM to be used by the application (it begins with a '/'), or a relative pathname from the default module location: /lib/security/ or /lib64/security/, depending on the architecture.

module-arguments are a space separated list of tokens that can be used to modify the specific behavior of the given PAM. Such arguments will be documented for each individual module. Note, if you wish to include spaces in an argument, you should surround that argument with square brackets.

```
    squid auth required pam_mysql.so user=passwd_query passwd=mada \

          db=eminence [query=select user_name from internet_service \

          where user_name='%u' and password=PASSWORD('%p') and \

        service='web_proxy']

```

When using this convention, you can include `[' characters inside the string, and if you wish to include a `]' character inside the string that will survive the argument parsing, you should use `\]'. In other words:

```
    [..[..\]..]    -->   ..[..]..

```

Any line in (one of) the configuration file(s), that is not formatted correctly, will generally tend (erring on the side of caution) to make the authentication process fail. A corresponding error is written to the system log files with a call to syslog(3).

More flexible than the single configuration file is it to configure libpam via the contents of pam.d directories. In this case the directories are filled with files each of which has a filename equal to a service-name (in lower-case): it is the personal configuration file for the named service.

Vendor-supplied PAM configuration files might be installed in the system directory /usr/lib/pam.d/ or a configurable vendor specific directory instead of the machine configuration directory /etc/pam.d/. If no machine configuration file is found, the vendor-supplied file is used. All files in /etc/pam.d/ override files with the same name in other directories.

The syntax of each file in pam.d is similar to that of the /etc/pam.conf file and is made up of lines of the following form:

```
type  control  module-path  module-arguments

```

The only difference being that the service-name is not present. The service-name is of course the name of the given configuration file. For example, /etc/pam.d/login contains the configuration for the login service.

## FILES
/etc/pam.conf

the configuration file

/etc/pam.d

the Linux-PAM configuration directory. Generally, if this directory is present, the /etc/pam.conf file is ignored.

/usr/lib/pam.d

the Linux-PAM vendor configuration directory. Files in /etc/pam.d override files with the same name in this directory.

## SEE ALSO
pam(3), PAM(8), pam_start(3)


title: pam_env.conf(5)

summary: the environment variables config files

text:
# pam_env.conf(5)

## NAME
pam_env.conf, environment - the environment variables config files

## DESCRIPTION
The /etc/security/pam_env.conf file specifies the environment variables to be set, unset or modified by pam_env(8). When someone logs in, this file is read and the environment variables are set according.

Each line starts with the variable name, there are then two possible options for each variable DEFAULT and OVERRIDE. DEFAULT allows an administrator to set the value of the variable to some default value, if none is supplied then the empty string is assumed. The OVERRIDE option tells pam_env that it should enter in its value (overriding the default value) if there is one to use. When OVERRIDE is not used, "" is assumed and no override will be done.

VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]

(Possibly non-existent) environment variables may be used in values using the ${string} syntax and (possibly non-existent) PAM_ITEMs as well as HOME and SHELL may be used in values using the @{string} syntax. Both the $ and @ characters can be backslash escaped to be used as literal values values can be delimited with "", escaped " not supported. Note that many environment variables that you would like to use may not be set by the time the module is called. For example, ${HOME} is used below several times, but many PAM applications don't make it available by the time you need it. The special variables @{HOME} and @{SHELL} are expanded to the values for the user from the corresponding passwd entry.

The "#" character at start of line (no space at front) can be used to mark this line as a comment line.

The /etc/environment file specifies the environment variables to be set. The file must consist of simple NAME=VALUE pairs on separate lines. The pam_env(8) module will read the file after the pam_env.conf file.

## EXAMPLES
These are some example lines which might be specified in /etc/security/pam_env.conf.

Set the REMOTEHOST variable for any hosts that are remote, default to "localhost" rather than not being set at all

```
      REMOTEHOST     DEFAULT=localhost OVERRIDE=@{PAM_RHOST}

```

Set the DISPLAY variable if it seems reasonable

```
      DISPLAY        DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}

```

Now some simple variables

```
      PAGER          DEFAULT=less

      MANPAGER       DEFAULT=less

      LESS           DEFAULT="M q e h15 z23 b80"

      NNTPSERVER     DEFAULT=localhost

      PATH           DEFAULT=${HOME}/bin:/usr/local/bin:/bin\

      :/usr/bin:/usr/local/bin/X11:/usr/bin/X11

      XDG_DATA_HOME  DEFAULT=@{HOME}/share/

```

Silly examples of escaped variables, just to show how they work.

```
      DOLLAR         DEFAULT=\$

      DOLLARDOLLAR   DEFAULT=        OVERRIDE=\$${DOLLAR}

      DOLLARPLUS     DEFAULT=\${REMOTEHOST}${REMOTEHOST}

      ATSIGN         DEFAULT=""      OVERRIDE=\@

```

## SEE ALSO
pam_env(8), pam.d(5), pam(8), environ(7)

## AUTHOR
pam_env was written by Dave Kinchlea <kinch@kinch.ark.com>.


pwhistory.conf

title: pwhistory.conf(5)

summary: pam_pwhistory configuration file

text:
# pwhistory.conf(5)

## NAME
pwhistory.conf - pam_pwhistory configuration file

## DESCRIPTION
pwhistory.conf provides a way to configure the default settings for saving the last passwords for each user. This file is read by the pam_pwhistory module and is the preferred method over configuring pam_pwhistory directly.

The file has a very simple name = value format with possible comments starting with # character. The whitespace at the beginning of line, end of line, and around the = sign is ignored.

## OPTIONS
debug

Turns on debugging via syslog(3).

enforce_for_root

If this option is set, the check is enforced for root, too.

remember=N

The last N passwords for each user are saved. The default is 10. Value of 0 makes the module to keep the existing contents of the opasswd file unchanged.

retry=N

Prompt user at most N times before returning with error. The default is 1.

file=/path/filename

Store password history in file /path/filename rather than the default location. The default location is /etc/security/opasswd.

## EXAMPLES
/etc/security/pwhistory.conf file example:

```
debug
remember=5
file=/tmp/opasswd

```

## FILES
/etc/security/pwhistory.conf

the config file for custom options

## SEE ALSO
pwhistory(8), pam_pwhistory(8), pam.conf(5), pam.d(5), pam(8)

## AUTHOR
pam_pwhistory was written by Thorsten Kukuk. The support for pwhistory.conf was written by Iker Pedrosa.


sepermit.conf

title: sepermit.conf(5)

text:
# sepermit.conf(5)

## NAME
sepermit.conf - configuration file for the pam_sepermit module

## DESCRIPTION
The lines of the configuration file have the following syntax:

<user>[:<option>:<option>...]

The user can be specified in the following manner:

•a username

•a groupname, with @group syntax. This should not be confused with netgroups.

•a SELinux user name with %seuser syntax.

The recognized options are:

exclusive

Only single login session will be allowed for the user and the user's processes will be killed on logout.

ignore

The module will never return PAM_SUCCESS status for the user. It will return PAM_IGNORE if SELinux is in the enforcing mode, and PAM_AUTH_ERR otherwise. It is useful if you want to support passwordless guest users and other confined users with passwords simultaneously.

The lines which start with # character are comments and are ignored.

## EXAMPLES
These are some example lines which might be specified in /etc/security/sepermit.conf.

```
%guest_u:exclusive
%staff_u:ignore
%user_u:ignore

```

## SEE ALSO
pam_sepermit(8), pam.d(5), pam(8), selinux(8),

## AUTHOR
pam_sepermit and this manual page were written by Tomas Mraz <tmraz@redhat.com>


time.conf

title: time.conf(5)

text:
# time.conf(5)

## NAME
time.conf - configuration file for the pam_time module

## DESCRIPTION
The pam_time PAM module does not authenticate the user, but instead it restricts access to a system and or specific applications at various times of the day and on specific days or over various terminal lines. This module can be configured to deny access to (individual) users based on their name, the time of day, the day of week, the service they are applying for and their terminal from which they are making their request.

For this module to function correctly there must be a correctly formatted /etc/security/time.conf file present. White spaces are ignored and lines maybe extended with '\' (escaped newlines). Text following a '#' is ignored to the end of the line.

The syntax of the lines is as follows:

services;ttys;users;times

In words, each rule occupies a line, terminated with a newline or the beginning of a comment; a '#'. It contains four fields separated with semicolons, ';'.

The first field, the services field, is a logic list of PAM service names that the rule applies to.

The second field, the tty field, is a logic list of terminal names that this rule applies to.

The third field, the users field, is a logic list of users or a netgroup of users to whom this rule applies.

A logic list namely means individual tokens that are optionally prefixed with '!' (logical not) and separated with '&' (logical and) and '|' (logical or).

For these items the simple wildcard '*' may be used only once. With netgroups no wildcards or logic operators are allowed.

The times field is used to indicate the times at which this rule applies. The format here is a logic list of day/time-range entries. The days are specified by a sequence of two character entries, MoTuSa for example is Monday Tuesday and Saturday. Note that repeated days are unset MoMo = no day, and MoWk = all weekdays bar Monday. The two character combinations accepted are Mo Tu We Th Fr Sa Su Wk Wd Al, the last two being week-end days and all 7 days of the week respectively. As a final example, AlFr means all days except Friday.

Each day/time-range can be prefixed with a '!' to indicate "anything but". The time-range part is two 24-hour times HHMM, separated by a hyphen, indicating the start and finish time (if the finish time is smaller than the start time it is deemed to apply on the following day).

For a rule to be active, ALL of service+ttys+users must be satisfied by the applying process.

Note, currently there is no daemon enforcing the end of a session. This needs to be remedied.

Poorly formatted rules are logged as errors using syslog(3).

## EXAMPLES
These are some example lines which might be specified in /etc/security/time.conf.

All users except for root are denied access to console-login at all times:

```
login ; tty* & !ttyp* ; !root ; !Al0000-2400

```

Games (configured to use PAM) are only to be accessed out of working hours. This rule does not apply to the user waster:

```
games ; * ; !waster ; Wd0000-2400 | Wk1800-0800

```

## SEE ALSO
pam_time(8), pam.d(5), pam(8)

## AUTHOR
pam_time was written by Andrew G. Morgan <morgan@kernel.org>.


console.apps

title: console.apps(5)

text:
# console.apps(5)

## NAME
console.apps - specify console-accessible privileged applications

## DESCRIPTION
The /etc/security/console.apps/ directory should contain one file per application that wishes to allow access to console users. The filename should be the same as the servicename, and the contents are irrelevant; the file may be a zero-length file. The application that the file is used by is free to specify the contents in any way that is useful for it.

## SEE ALSO
pam_console(8)

console.perms(5)

## AUTHOR
Michael K. Johnson <johnsonm@redhat.com>


console.handlers

title: console.handlers(5)

text:
# console.handlers(5)

## NAME
console.handlers - file specifying handlers of console lock and unlock events

## DESCRIPTION
/etc/security/console.handlers determines which programs will be run when an user obtains the console lock at login time, and when the user loses it on log out. It is read by the pam_console module.

The format is:

handler-filename lock|unlock [flag ...]

Where handler-filename is a name of the executable to be run, lock or unlock specifies on which event it should be run, and flags specify how should pam_console call it.

Additionally there should be a line which specifies glob patterns of console devices.

The format of this line is: console-name consoledevs regex [regex ...]

Where console-name is a name of the console class - currently ignored - and regexes are regular expression patterns which specify the name of the tty device. Only the first such line is consulted.

## FLAGS
logfail

The pam_console module should log error to the system log if the return value of the handler is not zero or if the handler can not be executed.

wait

The pam_console should wait for the handler to exit before continuing.

setuid

The handler should be executed with uid/gid of the user which obtained the console lock.

tty

The handler will get a tty name as obtained from PAM as a parameter.

user

The handler will get an user name as obtained from PAM as a parameter.

Anything else will be added directly as a parameter to the handler executable.

## SEE ALSO
pam_console(8)

## AUTHOR
Tomas Mraz <tmraz@redhat.com>


console.perms

title: console.perms(5)

text:
# console.perms(5)

## NAME
console.perms - permissions control file for users at the system console

## DESCRIPTION
/etc/security/console.perms and .perms files in the /etc/security/console.perms.d directory determine the permissions that will be given to priviledged users of the console at login time, and the permissions to which to revert when the users log out. They are read by the pam_console_apply helper executable.

The format is:

<class>=space-separated list of words

login-regexp|<login-class> perm dev-glob|<dev-class> \

revert-mode revert-owner[.revert-group]

The revert-mode, revert-owner, and revert-group fields are optional, and default to 0600, root, and root, respectively.

The words in a class definition are evaluated as globs if they refer to files, but as regular expressions if they apply to a console definition. Do not mix them.

Any line can be broken and continued on the next line by using a \ character as the last character on the line.

The login-class class and the login-regexp word are evaluated as regular expressions. The dev-class and the dev-glob word are evaluated as shell-style globs. If a name given corresponds to a directory, and if it is a mount point listed in /etc/fstab, the device node associated with the filesystem mounted at that point will be substituted in its place.

Classes are denoted by being contained in < angle bracket > characters; a lack of < angle brackets > indicates that the string is to be taken literally as a login-regexp or a dev-glob, depending on its input position.

## SEE ALSO
pam_console(8)

pam_console_apply(8)

console.apps(5)

## AUTHOR
Michael K. Johnson <johnsonm@redhat.com>