sepolicy-generate

title: sepolicy-generate(8)

text:
# sepolicy-generate(8)

## NAME
sepolicy-generate - Generate an initial SELinux policy module template.

## SYNOPSIS
Common options

sepolicy generate [-h ] [-p PATH]

Confined Applications

sepolicy generate --application [-n NAME] [-u USER ]command [-w WRITE_PATH ]

sepolicy generate --cgi [-n NAME] command [-w WRITE_PATH ]

sepolicy generate --dbus [-n NAME] command [-w WRITE_PATH ]

sepolicy generate --inetd [-n NAME] command [-w WRITE_PATH ]

sepolicy generate --init [-n NAME] command [-w WRITE_PATH ]

Confined Users

sepolicy generate --admin_user [-r TRANSITION_ROLE] -n NAME

sepolicy generate --confined_admin -n NAME [-a ADMIN_DOMAIN] [-u USER] [-n NAME] [-w WRITE_PATH]

sepolicy generate --desktop_user -n NAME [-w WRITE_PATH]

sepolicy generate --term_user -n NAME [-w WRITE_PATH]

sepolicy generate --x_user -n NAME [-w WRITE_PATH]

Miscellaneous Policy

sepolicy generate --customize -d DOMAIN -n NAME [-a ADMIN_DOMAIN]

sepolicy generate --newtype -t type -n NAME

sepolicy generate --sandbox -n NAME

## DESCRIPTION
Use sepolicy generate to generate an SELinux policy Module.

sepolicy generate will create 5 files.

When specifying a confined application you must specify a path. sepolicy generate will use the rpm payload of the application along with nm -D APPLICATION to help it generate types and policy rules for your policy files.

NAME.te

This file can be used to define all the types enforcement rules for a particular domain.

Note: Policy generated by sepolicy generate will automatically add a permissive DOMAIN to your .te file. When you are satisfied that your policy works, you need to remove the permissive line from the .te file to run your domain in enforcing mode.

NAME.if

This file defines the interfaces for the types generated in the .te file, which can be used by other policy domains.

NAME.fc

This file defines the default file context for the system, it takes the file types created in the .te file and associates file paths to the types. Tools like restorecon and RPM will use these paths to put down labels.

NAME_selinux.spec

This file is an RPM SPEC file that can be used to install the SELinux policy on to machines and setup the labeling. The spec file also installs the interface file and a man page describing the policy. You can use sepolicy manpage -d NAME to generate the man page.

NAME.sh

This is a helper shell script to compile, install and fix the labeling on your test system. It will also generate a man page based on the installed policy, and compile and build an RPM suitable to be installed on other machines.

## OPTIONS
-h, --help

Display help message

-d, --domain

Enter domain type(s) which you will be extending

-n, --name

Specify alternate name of policy. The policy will default to the executable or name specified

-p, --path

Specify the directory to store the created policy files. (Default to current working directory )

optional arguments:

-r, --role

Enter role(s) to which this admin user will transition

-t, --type

Enter type(s) for which you will generate new definition and rule(s)

-u, --user

SELinux user(s) which will transition to this domain

-w, --writepath

Path(s) which the confined processes need to write to

-a, --admin

Domain(s) which the confined admin will administrate

--admin_user

Generate Policy for Administrator Login User Role

--application

Generate Policy for User Application

--cgi

Generate Policy for Web Application/Script (CGI)

--confined_admin

Generate Policy for Confined Root Administrator Role

--customize

Generate Policy for Existing Domain Type

--dbus

Generate Policy for DBUS System Daemon

--desktop_user

Generate Policy for Desktop Login User Role

--inetd

Generate Policy for Internet Services Daemon

--init

Generate Policy for Standard Init Daemon (Default)

--newtype

Generate new policy for new types to add to an existing policy

--sandbox

Generate Policy for Sandbox

--term_user

Generate Policy for Minimal Terminal Login User Role

--x_user

Generate Policy for Minimal X Windows Login User Role

## EXAMPLE
> sepolicy generate --init /usr/sbin/rwhod

Generating Policy for /usr/sbin/rwhod named rwhod

Created the following files:

rwhod.te # Type Enforcement file

rwhod.if # Interface file

rwhod.fc # File Contexts file

rwhod_selinux.spec # Spec file

rwhod.sh # Setup Script

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


sepolicy-interface

package: policycoreutils-devel

title: sepolicy-interface(8)

text:
# sepolicy-interface(8)

## NAME
sepolicy-interface - Print interface information based on the installed SELinux Policy

## SYNOPSIS
sepolicy interface [-h] [-c] [-v] [-f FILE] [-a | -u | -l | -i INTERFACE [INTERFACE ... ]]

## DESCRIPTION
Use sepolicy interface to print information of interface macros between domains in SELinux policy modules, as used in Reference Policy. The information is based on installed on-disk representation of the SELinux Policy and it may be different from the policy which is currently loaded.

## OPTIONS
-a, --list_admin

List all domains with admin interface

-c, --compile

Test compile of interfaces

-h, --help

Display help message

-i, --interface

Interface(s) to be displayed

-l, --list

List all interfaces

-u, --list_user

List all domains with SELinux user role interface

-v, --verbose

Display extended information about the interface including parameters and description if available.

-f, --file

Interface file to be explored

## EXAMPLE

```
Show description of given interface
# sepolicy interface -vi samba_rw_config
List interfaces in given interface file and show their description
# sepolicy interface -f my_policy.if -lv
Run compile test for all interfaces in given file
# sepolicy interface -f my_policy.if -lc
```

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)

branch: sisyphus


sepolicy-manpage

title: sepolicy-manpage(8)

text:
# sepolicy-manpage(8)

## NAME
sepolicy-manpage - Generate a man page based on the installed SELinux Policy

## SYNOPSIS
sepolicy manpage [-w] [-h] [-p PATH ] [-r ROOTDIR ] [-a | -d ]

## DESCRIPTION
Use sepolicy manpage to generate manpages based on SELinux Policy.

## OPTIONS
-a, --all

Generate Man Pages for All Domains

-d, --domain

Generate a Man Page for the specified domain. (Supports multiple commands)

-h, --help

Display help message

-o, --os

Specify the name of the OS to be used in the man page (only affects HTML man pages)

-p, --path

Specify the directory to store the created man pages. (Default to /tmp)

-r, --root

Specify alternative root directory to generate man pages from. (Default to /)

--source_files

Use file_contexts and policy.xml files from the specified root directory (the alternative root needs to include both files)

-w, --web

Generate an additional HTML man pages for the specified domain(s)

## EXAMPLE

```
Generate man pages for all available domains
# sepolicy manpage -a
Generate an HTML man page for domain alsa_t, setting the OS name to "My_distro"
# sepolicy manpage -o My_distro -d alsa_t -w
```

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


sepolicy-network

title: sepolicy-network(8)

text:
# sepolicy-network(8)

## NAME
sepolicy-network - Examine the SELinux Policy and generate a network report

## SYNOPSIS
sepolicy network [-h] (-l | -a application [application ...] | -p PORT [PORT ...] | -t TYPE [TYPE ...] | -d DOMAIN [DOMAIN ...])

## DESCRIPTION
Use sepolicy network to examine SELinux Policy and generate network reports.

## OPTIONS
-a, --application

Generate a report listing the ports to which the specified init application is allowed to connect and or bind

-d, --domain

Generate a report listing the ports to which the specified domain is allowed to connect and or bind

-l, --list

List all Network Port Types defined in SELinux Policy

-h, --help

Display help message

-t, --type

Generate a report listing the port numbers associate with the specified SELinux port type

-p, --port

Generate a report listing the SELinux port types associate with the specified port number

## EXAMPLES
sepolicy network -p 22

22: tcp ssh_port_t 22

22: udp reserved_port_t 1-511

22: tcp reserved_port_t 1-511

sepolicy network -a /usr/sbin/sshd

sshd_t: tcp name_connect

111 (portmap_port_t)

53 (dns_port_t)

88, 750, 4444 (kerberos_port_t)

9080 (ocsp_port_t)

9180, 9701, 9443-9447 (pki_ca_port_t)

32768-61000 (ephemeral_port_t)

all ports < 1024 (reserved_port_type)

all ports with out defined types (port_t)

sshd_t: tcp name_bind

22 (ssh_port_t)

5900-5983, 5985-5999 (vnc_port_t)

6000-6020 (xserver_port_t)

32768-61000 (ephemeral_port_t)

all ports > 500 and < 1024 (rpc_port_type)

all ports with out defined types (port_t)

sshd_t: udp name_bind

32768-61000 (ephemeral_port_t)

all ports > 500 and < 1024 (rpc_port_type)

all ports with out defined types (port_t)

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8), semanage(8)


sepolicy-transition

title: sepolicy-transition(8)

text:
# sepolicy-transition(8)

## NAME
sepolicy-transition - Examine the SELinux Policy and generate a process transition report

## SYNOPSIS
sepolicy transition [-h] -s SOURCE

sepolicy transition [-h] -s SOURCE -t TARGET

## DESCRIPTION
sepolicy transition will show all domains that a given SELinux source domain can transition to, including the entrypoint.

If a target domain is given, sepolicy transition will examine policy for all transition paths from the source domain to the target domain, and will list the paths.

## OPTIONS
-h, --help

Display help message

-s, --source

Specify the source SELinux domain type

-t, --target

Specify the target SELinux domain type

## EXAMPLE

```
List all domain transition paths from init_t to httpd_t
# sepolicy transition -s init_t -t httpd_t
List all transitions available from samba domain, including entry points and booleans controlling each transition
# sepolicy transition -s smbd_t
```

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


selinux-polgengui

package: policycoreutils-gui

title: selinux-polgengui(8)

summary: SELinux Policy Generation Tool

text:
# selinux-polgengui(8)

## NAME
selinux-polgengui - SELinux Policy Generation Tool

## SYNOPSIS
selinux-polgengui

## DESCRIPTION
selinux-polgengui is a graphical tool, which can be used to create a framework for building SELinux Policy.

## OPTIONS
None

## FILES
/usr/bin/selinux-polgengui

## Examples
To run the program type:

selinux-polgengui

## SEE ALSO
selinux(1), sepolicy(8), sepolicy-generate(8)

## REPORTING BUGS
Report bugs to <http://bugzilla.redhat.com>.

## LICENSE AND AUTHORS
selinux-polgengui is licensed under the GNU General Public License and is copyrighted by Red Hat, Inc.

This man page was written by Daniel Walsh <dwalsh@redhat.com>


sepolicy-gui

title: sepolicy-gui(8)

text:
# sepolicy-gui(8)

## NAME
sepolicy-gui - Graphical User Interface for SELinux policy.

## SYNOPSIS
Common options

sepolicy gui [-h ] [ -d DOMAIN ]

## DESCRIPTION
Use sepolicy gui to run the graphical user interface, which allows you to explore how SELinux confines different process domains.

## OPTIONS
-h, --help

Display help message

-d, --domain

Initialize gui to the selected domain

## AUTHOR
This man page was written by Daniel Walsh <dwalsh@redhat.com>

## SEE ALSO
sepolicy(8), selinux(8)


system-config-selinux

title: system-config-selinux(8)

summary: SELinux Management tool

text:
# system-config-selinux(8)

## NAME
system-config-selinux - SELinux Management tool

## SYNOPSIS
system-config-selinux

## DESCRIPTION
system-config-selinux provides a graphical interface for managing the SELinux configuration.

## OPTIONS
None

## FILES
/usr/bin/system-config-selinux

## Examples
To run the program type:

system-config-selinux

## SEE ALSO
selinux(1), semanage(8)

## REPORTING BUGS
Report bugs to <http://bugzilla.redhat.com>.

## LICENSE AND AUTHORS
system-config-selinux is licensed under the GNU General Public License and is copyrighted by Red Hat, Inc.

This man page was written by Daniel Walsh <dwalsh@redhat.com>


mcs

package: policycoreutils-mcstransd

title: mcs(8)

summary: Multi-Category System

text:
# mcs(8)

## NAME
mcs - Multi-Category System

## DESCRIPTION
MCS (Multiple Category System) allows users to label files on their system within administrator defined categories. It then uses SELinux Mandatory Access Control to protect those files. MCS is a discretionary model to allow users to mark their data with additional tags that further restrict access. The only mandatory aspect is authorizing users for categories by defining their clearance in policy. However, MCS is similar to MLS and exercises the same code paths and share the same support infrastructure. They just differ in their specific configuration.

The /etc/selinux/{SELINUXTYPE}/setrans.conf configuration file translates the labels on disk to human readable form. Administrators can define any labels they want in this file. Certain applications like printing and auditing will use these labels to identify the files. By setting a category on a file you will prevent other applications/services from having access to the files.

Examples of file labels would be PatientRecord, CompanyConfidential etc.

## SEE ALSO
selinux(8), chcon(1)

## FILES
/etc/selinux/{SELINUXTYPE}/setrans.conf


mcstransd

title: mcstransd(8)

text:
# mcstransd(8)

## NAME
mcstransd - MCS (Multiple Category System) daemon. Translates SELinux MCS/MLS labels to human readable form.

## SYNOPSIS
mcstransd [-f] [-h]

## DESCRIPTION
This manual page describes the mcstransd program.

This daemon reads /etc/selinux/{SELINUXTYPE}/setrans.conf configuration file, and communicates with libselinux via a socket in /var/run/setrans.

## OPTIONS
-f

Run mcstransd in the foreground. Do not run as a daemon.

-h

Output a short summary of available command line options.

## AUTHOR
This man page was written by Dan Walsh <dwalsh@redhat.com>. The program was originally written by Dan Walsh <dwalsh@redhat.com>. The program was enhanced/rewritten by Joe Nall <joe@nall.com>.

## FILES
/etc/selinux/{SELINUXTYPE}/setrans.conf

## SEE ALSO
setrans.conf(5),mcs(8)


restorecond

package: policycoreutils-restorecond

title: restorecond(8)

text:
# restorecond(8)

## NAME
restorecond - daemon that watches for file creation and then sets the default SELinux file context

## SYNOPSIS
restorecond [-d] [-h] [-f restorecond_file ] [-u] [-v]

## DESCRIPTION
This manual page describes the restorecond program.

This daemon uses inotify to watch files listed in the /etc/selinux/restorecond.conf, when they are created, this daemon will make sure they have the correct file context associated with the policy.

## OPTIONS
-d

Turns on debugging mode. Application will stay in the foreground and lots of debugs messages start printing.

-h

Print usage statement.

-f restorecond_file

Use alternative restorecond.conf file.

-u

Turns on user mode. Runs restorecond in the user session and reads /etc/selinux/restorecond_user.conf. Uses dbus to make sure only one restorecond is running per user session.

-v

Turns on verbose debugging. (Report missing files)

## AUTHOR
This man page and program was written by Dan Walsh <dwalsh@redhat.com>.

## FILES
/etc/selinux/restorecond.conf /etc/selinux/restorecond_user.conf

## SEE ALSO
restorecon(8),


sandbox

package: policycoreutils-sandbox

title: sandbox(8)

summary: Run cmd under an SELinux sandbox

text:
# sandbox(8)

## NAME
sandbox - Run cmd under an SELinux sandbox

## SYNOPSIS
sandbox [-C] [-s] [ -d DPI ] [-l level ] [[-M | -X] -H homedir -T tempdir ] [ -R runuserdir ] [-I includefile ] [ -W windowmanager ] [ -w windowsize ] [[-i file ]...] [ -t type ] cmd

sandbox [-C] [-s] [ -d DPI ] [-l level ] [[-M | -X] -H homedir -T tempdir ] [ -R runuserdir ] [-I includefile ] [ -W windowmanager ] [ -w windowsize ] [[-i file ]...] [ -t type ] -S

## DESCRIPTION
Run the cmd application within a tightly confined SELinux domain. The default sandbox domain only allows applications the ability to read and write stdin, stdout and any other file descriptors handed to it. It is not allowed to open any other files. The -M option will mount an alternate homedir and tmpdir to be used by the sandbox.

If you have the policycoreutils-sandbox package installed, you can use the -X option and the -M option. sandbox -X allows you to run X applications within a sandbox. These applications will start up their own X Server and create a temporary home directory and /tmp. The default SELinux policy does not allow any capabilities or network access. It also prevents all access to the users other processes and files. Files specified on the command that are in the home directory or /tmp will be copied into the sandbox directories.

If directories are specified with -H or -T the directory will have its context modified with chcon(1) unless a level is specified with -l. If the MLS/MCS security level is specified, the user is responsible to set the correct labels.

-h --help

display usage message

-H --homedir

Use alternate homedir to mount over your home directory. Defaults to temporary. Requires -X or -M.

-i --include

Copy this file into the appropriate temporary sandbox directory. Command can be repeated.

-I --includefile

Copy all files listed in inputfile into the appropriate temporary sandbox directories.

-l --level

Specify the MLS/MCS Security Level to run the sandbox with. Defaults to random.

-M --mount

Create a Sandbox with temporary files for $HOME and /tmp.

-s --shred

Shred temporary files created in $HOME and /tmp, before deleting.

-t --type

Use alternate sandbox type, defaults to sandbox_t or sandbox_x_t for -X. Examples:

sandbox_t - No X, No Network Access, No Open, read/write on passed in file descriptors.

sandbox_min_t - No Network Access

sandbox_x_t - Ports for X applications to run locally

sandbox_web_t - Ports required for web browsing

sandbox_net_t - Network ports (for server software)

sandbox_net_client_t - All network ports

-T --tmpdir

Use alternate temporary directory to mount on /tmp. Defaults to tmpfs. Requires -X or -M.

-R --runuserdir

Use alternate temporary directory to mount on XDG_RUNTIME_DIR (/run/user/$UID).

-S --session

Run a full desktop session, Requires level, and home and tmpdir.

-w --windowsize

Specifies the windowsize when creating an X based Sandbox. The default windowsize is 1000x700.

-W --windowmanager

Select alternative window manager to run within sandbox -X. Default to /usr/bin/openbox.

-X

Create an X based Sandbox for gui apps, temporary files for $HOME and /tmp, secondary Xserver, defaults to sandbox_x_t

-d --dpi

Set the DPI value for the sandbox X Server. Defaults to the current X Sever DPI.

-C --capabilities

Use capabilities within the sandbox. By default applications executed within the sandbox will not be allowed to use capabilities (setuid apps), with the -C flag, you can use programs requiring capabilities.

## SEE ALSO
runcon(1), seunshare(8), selinux(8)

## EXAMPLE

```
Run a graphical application inside the sandbox
# sandbox -X evince
Run a graphical application that requires the use of network
# sandbox ‑X ‑t sandbox_web_t firefox
Preserve data from one session to the next
# mkdir -p ~/sandbox/home ~/sandbox/tmp
# sandbox -H ~/sandbox/home -T ~/sandbox/tmp -X libreoffice --writer
```

## AUTHOR
This manual page was written by Dan Walsh <dwalsh@redhat.com> and Thomas Liu <tliu@fedoraproject.org>


seunshare

title: seunshare(8)

text:
# seunshare(8)

## NAME
seunshare - Run cmd with alternate homedir, tmpdir and/or SELinux context

## SYNOPSIS
seunshare [ -v ] [ -C ] [ -k ] [ -t tmpdir ] [ -h homedir ] [ -Z context ] -- executable [args]

## DESCRIPTION
Run the executable within the specified context, using custom home directory and /tmp directory. The seunshare command unshares from the default namespace, then mounts the specified homedir and tmpdir over the default homedir and /tmp. Finally it tells the kernel to execute the application under the specified SELinux context.

-h homedir

Alternate homedir to be used by the application. Homedir must be owned by the user

-t tmpdir

Use alternate temporary directory to mount on /tmp. tmpdir must be owned by the user

-r runuserdir

Use alternate temporary directory to mount on XDG_RUNTIME_DIR (/run/user/$UID). runuserdir must be owned by the user

-C --capabilities

Allow apps executed within the namespace to use capabilities. Default is no capabilities

-k --kill

Kill all processes with matching MCS level

-Z context

Use alternate SELinux context while running the executable

-v

Verbose output

## EXAMPLE

```
Run bash with temporary /home and /tmp directory
# USERHOMEDIR=`mktemp -d /tmp/home.XXXXXX`; USERTEMPDIR=`mktemp -d /tmp/temp.XXXXXX`
# seunshare -v -h ${USERHOMEDIR} -t ${USERTEMPDIR} -- /bin/bash
```

## SEE ALSO
runcon(1), sandbox(8), selinux(8)

## AUTHOR
This manual page was written by Dan Walsh <dwalsh@redhat.com> and Thomas Liu <tliu@fedoraproject.org>


policyd-weight

package: policyd-weight

title: policyd-weight(8)

summary: weighted SMTP policy daemon

text:
# policyd-weight(8)

## NAME
policyd-weight - weighted SMTP policy daemon

## STATUS
Beta, Documentation incomplete

## SYNOPSIS

```

```

policyd-weight [-option] [-option2 <arg>] command

## DESCRIPTION

policyd-weight(8) is a SMTP policy daemon written in perl(1) for postfix(1). It evaluates based on RBL/RHSBL results, HELO and MAIL FROM domain and subdomain arguments and the client IP address the possibility of forgery or SPAM. It is designed to be called before the SMTP DATA command at the RCPT TO stage. This way it is a) possible to reject a mail attempt before the body has been received and b) to keep multirecipient mail intact, i.e. provide the functionality of selective usage based on recipients.

To make policyd-weight(8) work with postfix(1), it is required to add a system account for $USER (default: polw)

Policyd-weight can operate in master.cf or daemon mode. In master.cf mode it uses postfix' spawn(8), which results in number of simultanous requests perl instances. In daemon mode it uses shared memory and forks on load, and only if all childs are busy.

At the time of writing the man-pages for policyd-weight assume a postfix installation. It has been reported that policyd-weight works with other MTAs like Exim, too.

## master.cf mode:
master.cf:

policy unix - n n - - spawn user=polw

argv=/usr/bin/perl /usr/local/bin/policyd-weight

main.cf:

smtpd_recipient_restrictions =

permit_mynetworks,

... authenticated permits ...

reject_unauth_destination,

... whitelists, role accounts, clients ...

check_policy_service unix:private/policy

## daemon mode:
start the daemon with policyd-weight start. Poliyd-weight then listens on $TCP_PORT (default: 12525) for policy requests. To make postfix talk to that port do following changes to main.cf:

main.cf:

smtpd_recipient_restrictions =

permit_mynetworks,

... authenticated permits ...

reject_unauth_destination,

... whitelists, role accounts, clients ...

check_policy_service inet:127.0.0.1:12525

It is possible to have more than one postfix server talk to the daemonized policyd-weight by configuring each postfix machine to query the policy server with check_policy_service inet:IP:12525 where IP is the host on which policyd-weight runs.

Please note that check_policy_service should come at last, or at least after reject_unauth_destination, or else you may become an open relay.

## COMMANDS

Following commands exist and are reserved for daemon mode only:

start start the policy server

stop stop the policy server

restart restart the policy server

reload tells the policy server to reload its configuration

defaults prints the default settings to STDOUT and exits

## OPTIONS

-d operate in debug mode

Not for use in master.cf. In debug mode everything is reported on STDOUT instead of syslog(3). Also an own debug cache daemon will be spawned. The socket-file is named after the value of $SPATH with ".debug" as suffix.

-f /path/to/file

Pass a configuration file to policyd-weight

-h show help

-k kill cache daemon

Not for use in master.cf. Together with -d this kills the debug cache daemon. Without -d it kills the global running cache daemon.

-s show cache entries

Not for use in master.cf.

-v show version

## LOGGING

Logging is done via syslog(3) with facility "mail" and priority "info". For a complete list of log entries and their correspondending configuration parameters refer to policyd-weight.conf(5).

## BUGS

```
Please report bugs to r.felber@ek-muc.de
```

## HISTORY

March 2005

Ralf Hildebrandt (Author of the Book of Postfix) is the spiritual father of policyd-weight. It was his idea to have a scored RBL evaluation, I've added the weighted MAIL FROM/HELO DNS-evaluation. For that purpose I used Meng Wong's spf.pl which was shipped with the postfix source as example.

## FILES

```
/etc/policyd-weight.conf, Policyd-weight configuration file
/etc/postfix/main.cf, Postfix configuration parameters
/etc/postfix/master.cf, Postfix daemon processes
```

## SEE ALSO

```
policyd-weight.conf(5), Policyd-weight configuration file
master(5), Postfix master.cf file syntax
postconf(5), Postfix main.cf file syntax
access(5), Postfix SMTP access control table
```

## LICENSE

```
GNU General Public License
```

## AUTHOR

```
Robert Felber <r.felber@ek-muc.de>
Autohaus Erich Kuttendreier
81827 Munich, Germany
```


polkit

package: polkit

title: polkit(8)

summary: Authorization Manager

text:
# polkit(8)

## NAME
polkit - Authorization Manager

## OVERVIEW
polkit provides an authorization API intended to be used by privileged programs (“MECHANISMS”) offering service to unprivileged programs (“SUBJECTS”) often through some form of inter-process communication mechanism. In this scenario, the mechanism typically treats the subject as untrusted. For every request from a subject, the mechanism needs to determine if the request is authorized or if it should refuse to service the subject. Using the polkit APIs, a mechanism can offload this decision to a trusted party: The polkit authority.

The polkit authority is implemented as an system daemon, polkitd(8), which itself has little privilege as it is running as the polkitd system user. Mechanisms, subjects and authentication agents communicate with the authority using the system message bus.

In addition to acting as an authority, polkit allows users to obtain temporary authorization through authenticating either an administrative user or the owner of the session the client belongs to. This is useful for scenarios where a mechanism needs to verify that the operator of the system really is the user or really is an administrative user.

## SYSTEM ARCHITECTURE
The system architecture of polkit is comprised of the Authority (implemented as a service on the system message bus) and an Authentication Agent per user session (provided and started by the user's graphical environment). Actions are defined by applications. Vendors, sites and system administrators can control authorization policy through Authorization Rules.

[IMAGE][1]

```
 +-------------------+

 |   Authentication  |

 |       Agent       |

 +-------------------+

 | libpolkit-agent-1 |

 +-------------------+

        ^                                  +---------+

        |                                  | Subject |

        +--------------+                   +---------+

                       |                        ^

                       |                        |
User Session           |                        |
=======================|========================|=============
System Context         |                        |

                       |                        |

                       |                    +---+

                       V                    |

                     /------------\         |

                     | System Bus |         |

                     \------------/         |

                       ^        ^           V

                       |        |      +---------------------+

        +--------------+        |      |      Mechanism      |

        |                       |      +---------------------+

        V                       +----> | libpolkit-gobject-1 |
+------------------+                   +---------------------+
|    polkitd(8)    |
+------------------+
| org.freedesktop. |
|    PolicyKit1    |<---------+
+------------------+          |

          ^                   |

          |            +--------------------------------------------+

          |            | /etc/polkit-1/actions/*.policy             |

          |            | /run/polkit-1/actions/*.policy             |

          |            | /usr/local/share/polkit-1/actions/*.policy |

          |            | /usr/share/polkit-1/actions/*.policy       |

          |            +--------------------------------------------+

          |

   +--------------------------------------------+

   | /etc/polkit-1/rules.d/*.rules              |

   | /run/polkit-1/rules.d/*.rules              |

   | /usr/local/share/polkit-1/rules.d/*.rules  |

   | /usr/share/polkit-1/rules.d/*.rules        |

   +--------------------------------------------+
```

For convenience, the libpolkit-gobject-1 library wraps the polkit D-Bus API and is usable from any C/C++ program as well as higher-level languages supporting GObjectIntrospection[2] such as JavaScript and Python. A mechanism can also use the D-Bus API or the pkcheck(1) command to check authorizations. The libpolkit-agent-1 library provides an abstraction of the native authentication system, e.g. pam(8) and also facilities for registration and communication with the polkit D-Bus service.

See the developer documentation[3] for more information about writing polkit applications.

## AUTHENTICATION AGENTS
An authentication agent is used to make the user of a session prove that the user of the session really is the user (by authenticating as the user) or an administrative user (by authenticating as an administrator). In order to integrate well with the rest of the user session (e.g. match the look and feel), authentication agents are meant to be provided by the user session that the user uses. For example, an authentication agent may look like this:

[IMAGE][4]

```
+----------------------------------------------------------+
|                                                          |
|  [Icon]  Authentication required                         |
|                                                          |
|          Authentication is required to format INTEL      |
|          SSDSA2MH080G1GC (/dev/sda)                      |
|                                                          |
|          Administrator                                   |
|                                                          |
|          Password: [__________________________________]  |
|                                                          |
| [Cancel]                                  [Authenticate] |
+----------------------------------------------------------+
```

If the system is configured without a root account, it may prompt for a specific user designated as the administrative user:

[IMAGE][5]

```
+----------------------------------------------------------+
|                                                          |
|  [Icon]  Authentication required                         |
|                                                          |
|          Authentication is required to format INTEL      |
|          SSDSA2MH080G1GC (/dev/sda)                      |
|                                                          |
|          [Icon] David Zeuthen                            |
|                                                          |
|          Password: [__________________________________]  |
|                                                          |
| [Cancel]                                  [Authenticate] |
+----------------------------------------------------------+
```

Applications that do not run under a desktop environment (for example, if launched from an ssh(1) login) may not have an authentication agent associated with them. Such applications may use the PolkitAgentTextListener type or the pkttyagent(1) helper so the user can authenticate using a textual interface.

## DECLARING ACTIONS
A mechanism needs to declare a set of actions in order to use polkit. Actions correspond to operations that clients can request the mechanism to carry out and are defined in XML files that the mechanism installs into the /usr/share/polkit-1/actions directory.

polkit actions are namespaced and can only contain the characters "[A-Z][a-z][0-9].-", e.g. ASCII, digits, period and hyphen. Each XML file can contain more than one action but all actions need to be in the same namespace and the file needs to be named after the namespace and have the extension .policy.

The XML file must have the following doctype declaration

```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD polkit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
```

The policyconfig element must be present exactly once. Elements that can be used inside policyconfig includes:

vendor

The name of the project or vendor that is supplying the actions in the XML document. Optional.

vendor_url

A URL to the project or vendor that is supplying the actions in the XML document. Optional.

icon_name

An icon representing the project or vendor that is supplying the actions in the XML document. The icon name must adhere to the Freedesktop.org Icon Naming Specification[6]. Optional.

action

Declares an action. The action name is specified using the id attribute and can only contain the characters "[A-Z][a-z][0-9].- ", e.g. ASCII, digits, period and hyphen.

Elements that can be used inside action include:

description

A human readable description of the action, e.g. “Install unsigned software”.

message

A human readable message displayed to the user when asking for credentials when authentication is needed, e.g. “Installing unsigned software requires authentication”.

defaults

This element is used to specify implicit authorizations for clients. Elements that can be used inside defaults include: allow_any

Implicit authorizations that apply to any client. Optional.

allow_inactive

Implicit authorizations that apply to clients in inactive sessions on local consoles. Optional.

allow_active

Implicit authorizations that apply to clients in active sessions on local consoles. Optional.

Each of the allow_any, allow_inactive and allow_active elements can contain the following values:

no

Not authorized.

yes

Authorized.

auth_self

Authentication by the owner of the session that the client originates from is required. Note that this is not restrictive enough for most uses on multi-user systems; auth_admin* is generally recommended.

auth_admin

Authentication by an administrative user is required.

auth_self_keep

Like auth_self but the authorization is kept for a brief period (e.g. five minutes). The warning about auth_self above applies likewise.

auth_admin_keep

Like auth_admin but the authorization is kept for a brief period (e.g. five minutes).

annotate

Used for annotating an action with a key/value pair. The key is specified using the key attribute and the value is specified using the value attribute. This element may appear zero or more times. See below for known annotations.

vendor

Used for overriding the vendor on a per-action basis. Optional.

vendor_url

Used for overriding the vendor URL on a per-action basis. Optional.

icon_name

Used for overriding the icon name on a per-action basis. Optional.

For localization, description and message elements may occur multiple times with different xml:lang attributes.

To list installed polkit actions, use the pkaction(1) command.

### Known annotations
The org.freedesktop.policykit.exec.path annotation is used by the pkexec program shipped with polkit - see the pkexec(1) man page for details.

The org.freedesktop.policykit.imply annotation (its value is a string containing a space-separated list of action identifiers) can be used to define meta actions. The way it works is that if a subject is authorized for an action with this annotation, then it is also authorized for any action specified by the annotation. A typical use of this annotation is when defining an UI shell with a single lock button that should unlock multiple actions from distinct mechanisms.

The org.freedesktop.policykit.owner annotation can be used to define a set of users who can query whether a client is authorized to perform this action. If this annotation is not specified, then only root can query whether a client running as a different user is authorized for an action. The value of this annotation is a string containing a space-separated list of PolkitIdentity entries, for example "unix-user:42 unix-user:colord". A typical use of this annotation is for a daemon process that runs as a system user rather than root.

## AUTHORIZATION RULES
polkitd reads .rules files from the following directories in this order:

•/etc/polkit-1/rules.d

•/run/polkit-1/rules.d

•/usr/local/share/polkit-1/rules.d

•/usr/share/polkit-1/rules.d

These directories are processed in lexical order based on the basename of each file. If there's a tie, files in directories earlier in the list are processed first. For example, for the following four files, the order is:

•/etc/polkit-1/rules.d/10-auth.rules

•/run/polkit-1/rules.d/10-auth.rules

•/usr/local/share/polkit-1/rules.d/10-auth.rules

•/usr/share/polkit-1/rules.d/10-auth.rules

All of these directories are monitored, so if a rules file is changed, added, or removed, existing rules are purged and all files are read and processed again. Rules files are written in the JavaScript[7] programming language and interface with polkitd through the global polkit object (of type Polkit).

While the JavaScript interpreter used in particular versions of polkit may support non-standard features (such as the let keyword), authorization rules must conform to ECMA-262 edition 5[8] (in other words, the JavaScript interpreter used may change in future versions of polkit).

Authorization rules are intended for two specific audiences

•System Administrators

•Special-purpose Operating Systems / Environments

and those audiences only. In particular, applications, mechanisms and general-purpose operating systems must never include any authorization rules.

### The Polkit type
The following methods are available on the polkit object:

void addRule(polkit.Result function(action, subject) {...});

void addAdminRule(string[] function(action, subject) {...});

void log(string message);

string spawn(string[] argv);

The addRule() method is used for adding a function that may be called whenever an authorization check for action and subject is performed. Functions are called in the order they have been added until one of the functions returns a value. Hence, to add an authorization rule that is processed before other rules, put it in a file in /etc/polkit-1/rules.d with a name that sorts before other rules files, for example 00-early-checks.rules. Each function should return a value from polkit.Result

```
polkit.Result = {

    NO              : "no",

    YES             : "yes",

    AUTH_SELF       : "auth_self",

    AUTH_SELF_KEEP  : "auth_self_keep",

    AUTH_ADMIN      : "auth_admin",

    AUTH_ADMIN_KEEP : "auth_admin_keep",

    NOT_HANDLED     : null
};
```

corresponding to the values that can be used as defaults. If the function returns polkit.Result.NOT_HANDLED, null, undefined or does not return a value at all, the next user function is tried.

Keep in mind that if polkit.Result.AUTH_SELF_KEEP or polkit.Result.AUTH_ADMIN_KEEP is returned, authorization checks for the same action identifier and subject will succeed (that is, return polkit.Result.YES) for the next brief period (e.g. five minutes) even if the variables passed along with the check are different. Therefore, if the result of an authorization rule depend on such variables, it should not use the "*_KEEP" constants (if similar functionality is required, the authorization rule can easily implement temporary authorizations using the Date[9] type for timestamps).

The addAdminRule() method is used for adding a function that may be called whenever administrator authentication is required. The function is used to specify what identities may be used for administrator authentication for the authorization check identified by action and subject. Functions added are called in the order they have been added until one of the functions returns a value. Each function should return an array of strings where each string is of the form "unix-group:<group>", "unix-netgroup:<netgroup>" or "unix-user:<user>". If the function returns null, undefined or does not return a value at all, the next function is tried.

There is no guarantee that a function registered with addRule() or addAdminRule() is ever called - for example an early rules file could register a function that always returns a value, hence ensuring that functions added later are never called.

If user-provided code takes a long time to execute, no exception will be thrown and the script will be killed right away (the current limit is 15 seconds). This is used to catch runaway scripts.

The spawn() method spawns an external helper identified by the argument vector argv and waits for it to terminate. If an error occurs or the helper doesn't exit normally with exit code 0, an exception is thrown. If the helper does not exit within 10 seconds, it is killed. Otherwise, the program's standard output is returned as a string. The spawn() method should be used sparingly as helpers may take a very long or indeterminate amount of time to complete and no other authorization check can be handled while the helper is running. Note that the spawned programs will run as the unprivileged polkitd system user.

The log() method writes the given message to the system logger prefixed with the JavaScript filename and line number. Log entries are emitted using the LOG_AUTHPRIV flag meaning that the log entries usually ends up in the file /var/log/secure. The log() method is usually only used when debugging rules. The Action and Subject types has suitable toString() methods defined for easy logging, for example,

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.policykit.exec") {

        polkit.log("action=" + action);

        polkit.log("subject=" + subject);

    }
});
```

will produce the following when the user runs 'pkexec -u bateman bash -i' from a shell:

```
May 24 14:28:50 thinkpad polkitd[32217]: /etc/polkit-1/rules.d/10-test.rules:3: action=[Action id='org.freedesktop.policykit.exec' command_line='/usr/bin/bash -i' program='/usr/bin/bash' user='bateman' user.gecos='Patrick Bateman' user.display='Patrick Bateman (bateman)']
May 24 14:28:50 thinkpad polkitd[32217]: /etc/polkit-1/rules.d/10-test.rules:4: subject=[Subject pid=1352 user='davidz' groups=davidz,wheel, seat='seat0' session='1' local=true active=true]
```

### The Action type
The action parameter passed to user functions is an object with information about the action being checked. It is of type Action and has the following attribute:

string id

The action identifier, for example org.freedesktop.policykit.exec.

The following methods are available on the Action type:

string lookup(string key);

The lookup() method is used to lookup the polkit variables passed from the mechanism. For example, the pkexec(1) mechanism sets the variable program which can be obtained in JavaScript using the expression action.lookup("program"). If there is no value for the given key, then undefined is returned.

Consult the documentation for each mechanism for what variables are available for each action.

### The Subject type
The subject parameter passed to user functions is an object with information about the process being checked. It is of type Subject and has the following attributes

int pid

The process id.

string user

The user name.

string[] groups

Array of groups that user user belongs to.

string seat

The seat that the subject is associated with - blank if not on a local seat.

string session

The session that the subject is associated with.

string system_unit

The systemd unit that the subject's process is part of (if any). Note that this can only match on system units, as user units can be created with any name without privileges (unlike system units which require root to create). A process running in a user unit will return the user session unit in this attribute (e.g.: user-1000.service).

boolean local

Set to true only if seat is local.

boolean no_new_privileges

Set only if system_unit is not empty, and set to true only if the referenced systemd service unit has the NoNewPrivileges= setting enabled. This ensures that the process cannot gain any new privileges via executing setuid binaries.

boolean active

Set to true only if the session is active.

The following methods are available on the Subject type:

boolean isInGroup(string groupName);

boolean isInNetGroup(string netGroupName);

The isInGroup() method can be used to check if the subject is in a given group and isInNetGroup() can be used to check if the subject is in a given netgroup.

### Authorization Rules Examples
Allow all users in the admin group to perform user administration without changing policy for other users:

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.accounts.user-administration" &&

        subject.isInGroup("admin")) {

        return polkit.Result.YES;

    }
});
```

Define administrative users to be the users in the wheel group:

```
polkit.addAdminRule(function(action, subject) {

    return ["unix-group:wheel"];
});
```

Forbid users in group children to change hostname configuration (that is, any action with an identifier starting with org.freedesktop.hostname1.) and allow anyone else to do it after authenticating as themselves:

```
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.hostname1.") == 0) {

        if (subject.isInGroup("children")) {

            return polkit.Result.NO;

        } else {

            return polkit.Result.AUTH_SELF_KEEP;

        }

    }
});
```

Run an external helper to determine if the current user may reboot the system:

```
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.login1.reboot") == 0) {

        try {

            // user-may-reboot exits with success (exit code 0)

            // only if the passed username is authorized

            polkit.spawn(["/opt/company/bin/user-may-reboot",

                          subject.user]);

            return polkit.Result.YES;

        } catch (error) {

            // Nope, but do allow admin authentication

            return polkit.Result.AUTH_ADMIN;

        }

    }
});
```

The following example shows how the authorization decision can depend on variables passed by the pkexec(1) mechanism:

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.policykit.exec" &&

        action.lookup("program") == "/usr/bin/cat") {

        return polkit.Result.AUTH_ADMIN;

    }
});
```

The following example shows another use of variables passed from the mechanism. In this case, the mechanism is UDisks[10] which defines a set of actions and variables[11] that is used to match on:

```
// Allow users in group 'engineers' to perform any operation on
// some drives without having to authenticate
//
polkit.addRule(function(action, subject) {

    if (action.id.indexOf("org.freedesktop.udisks2.") == 0 &&

        action.lookup("drive.vendor") == "SEAGATE" &&

        action.lookup("drive.model") == "ST3300657SS" &&

        subject.isInGroup("engineers")) {

            return polkit.Result.YES;

        }

    }
});
```

Allow all processes running as part of the admin.service systemd system unit to perform user administration, as long as they cannot gain new privileges:

```
polkit.addRule(function(action, subject) {

    if (action.id == "org.freedesktop.accounts.user-administration" &&

        subject.system_unit == "admin.service" &&

        subject.no_new_privileges) {

        return polkit.Result.YES;

    }
});
```

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others.

## BUGS
Please send bug reports to either the distribution or the polkit-devel mailing list, see the link https://gitlab.freedesktop.org/polkit/polkit/-/issues/ on how to subscribe.

## SEE ALSO
polkitd(8), pkaction(1), pkcheck(1), pkexec(1), pkttyagent(1)

## NOTES
1.

/usr/share/gtk-doc/html/polkit-1/polkit-architecture.png

2.

GObjectIntrospection

https://live.gnome.org/GObjectIntrospection

3.

developer documentation

http://www.freedesktop.org/software/polkit/docs/latest/

4.

/usr/share/gtk-doc/html/polkit-1/polkit-authentication-agent-example.png

5.

/usr/share/gtk-doc/html/polkit-1/polkit-authentication-agent-example-wheel.png

6.

Freedesktop.org Icon Naming Specification

http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

7.

JavaScript

http://en.wikipedia.org/wiki/JavaScript

8.

ECMA-262 edition 5

http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_5th_Edition

9.

Date

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

10.

UDisks

http://udisks.freedesktop.org/docs/latest/udisks.8.html

11.

actions and variables

http://udisks.freedesktop.org/docs/latest/udisks-polkit-actions.html


polkitd

title: polkitd(8)

summary: The polkit system daemon

text:
# polkitd(8)

## NAME
polkitd - The polkit system daemon

## SYNOPSIS
polkitd

## DESCRIPTION
polkitd provides the org.freedesktop.PolicyKit1 D-Bus service on the system message bus. Users or administrators should never need to start this daemon as it will be automatically started by dbus-daemon(1) or systemd(1) whenever an application calls into the service.

polkitd must be started with superuser privileges but drops privileges early by switching to the unprivileged polkitd system user.

See the polkit(8) man page for more information.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others.

## BUGS
Please send bug reports to either the distribution or the polkit-devel mailing list, see the link https://gitlab.freedesktop.org/polkit/polkit/-/issues/ on how to subscribe.

## SEE ALSO
polkit(8), pkaction(1), pkcheck(1), pkexec(1), pkttyagent(1), dbus-daemon(1), systemd(1)


pkla-admin-identities

package: polkit-pkla-compat

title: pkla-admin-identities(8)

summary: List pklocalauthority\-configured polkit administrators

text:
# pkla-admin-identities(8)

## NAME
pkla-admin-identities - List pklocalauthority-configured polkit administrators

## SYNOPSIS
pkla-admin-identities [--help]

pkla-admin-identities [--config-path config-path]

## DESCRIPTION
pkla-admin-identities interprets configuration files described below to determine which users polkit(8) considers administrators, using a non-JavaScript configuration file format described below.

Note: Determining which users are considered administrators is driven by JavaScript rules as described in polkit(8). pkla-admin-identities is called by a JavaScript rule file named 49-polkit-pkla-compat.rules; other JavaScript rules with a higher priority may exist, so the pkla-admin-identities configuration may not necessarily govern the final decision by polkit(8).

The ordering of the JavaScript rule files and the ordering of pkla-admin-identities configuration files is not integrated and uses different rules; the pkla-admin-identities configuration evaluation is happens at a single point within the JavaScript rule evaluation order.

pkla-admin-identities is an internal helper program of pkla-polkit-compat. You shouldn't need to run it directly, except for debugging purposes.

Configuration is read from files with a .conf extension in the /etc/polkit-1/localauthority.conf.d directory. All files are read in lexicographical order (using the C locale), meaning that later files can override earlier ones. The file 50-localauthority.conf contains the settings provided by the OS vendor. Users and 3rd party packages can drop configuration files with a priority higher than 60 to change the defaults. The configuration file format is simple. Each configuration file is a key file (also commonly known as a ini file) with a single group called [Configuration]. Only a single key, AdminIdentities is read. The value of this key is a semi-colon separated list of identities that can be used when administrator authentication is required. Users are specified by prefixing the user name with unix-user:, groups of users are specified by prefixing with unix-group:, and netgroups of users are specified with unix-netgroup:. See the section called “EXAMPLE” for an example of a configuration file.

pkla-admin-identities outputs the resulting configuration of administrator identities, one identity per line, using the same format (including e.g. the unix-user: prefix). If no administrator identities are configured in the above-described configuration files, the output will be empty.

## OPTIONS
-h, --help

Write a summary of the available options to standard output and exit successfully.

-c, --config-path=config-path

Search for configuration files in config-path instead of the default /etc/polkit-1/localauthority.conf.d.

## EXIT STATUS
pkla-admin-identities exits with 0 on success (even if there are no administrator identities), and a non-zero status on error.

## FILES
/etc/polkit-1/localauthority.conf.d

Default directory containing configuration files.

## EXAMPLE
The following .conf file

```
[Configuration]
AdminIdentities=unix-group:staff

```

specifies that any user in the staff UNIX group can be used for authentication when administrator authentication is needed. This file would typically be installed in the /etc/polkit-1/localauthority.conf.d directory and given the name 60-desktop-policy.conf to ensure that it is evaluated after the 50-localauthority.conf file shipped with pkla-polkit-compat. If the local administrator wants to override this (suppose 60-desktop-policy.conf was shipped as part of the OS) he can simply create a file 99-my-admin-configuration.conf with the following content

```
[Configuration]
AdminIdentities=unix-user:lisa;unix-user:marge

```

to specify that only the users lisa and marge can authenticate when administrator authentication is needed.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others. Adapted by Miloslav Trmač <mitr@redhat.com>.

## SEE ALSO
polkit(8)


pkla-check-authorization

title: pkla-check-authorization(8)

text:
# pkla-check-authorization(8)

## NAME
pkla-check-authorization - Evaluate pklocalauthority authorization configuration

## SYNOPSIS
pkla-check-authorization [--help]

pkla-check-authorization [--paths paths] {user-name} {is-local} {is-active} {action}

## DESCRIPTION
pkla-check-authorization interprets non-JavaScript configuration files described below to determine the response of polkit(8) to authorization queries.

Note: Authorization decision evaluation is driven by JavaScript rules as described in polkit(8). pkla-check-authorization is called by a JavaScript rule file named 49-polkit-pkla-compat.rules; other JavaScript rules with a higher priority may exist, so the pkla-check-authorization configuration may not necessarily govern the final polkit(8) authorization decision.

The ordering of the JavaScript rule files and the ordering of pkla-check-authorization configuration files is not integrated and uses different rules; the pkla-check-authorization configuration evaluation is happens at a single point within the JavaScript rule evaluation order.

pkla-check-authorization is an internal helper program of pkla-polkit-compat. You shouldn't need to run it directly, except for debugging purposes.

The arguments to pkla-check-authorization are, in order:

user-name

Name of the user account asking for authorization

is-local

Whether the attempted action is performed from a local login session, true or false.

is-active

Whether the attempted action is performed from a currently active session (e.g. currently active virtual console), true or false.

action

A string identifying the polkit(8) action.

If the configuration specifies an authorization decision, pkla-check-authorization outputs the decision and a terminating newline. If no decision is configured, the output is empty.

## OPTIONS
-h, --help

Write a summary of the available options to standard output and exit successfully.

-p, --paths=paths

Search for configuration files in semicolon-separated paths instead of the default /var/lib/polkit-1/localauthority;/etc/polkit-1/localauthority.

## EXIT STATUS
pkla-check-authorization exits with 0 on success (even if there is no decision configured), and a non-zero status on error.

## DIRECTORY STRUCTURE
Files with .pkla extension are read from all directories located inside the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories (or as specified using the --paths option). By default, the following sub-directories are installed.

```
/etc/polkit-1/
`-- localauthority

    |-- 10-vendor.d

    |-- 20-org.d

    |-- 30-site.d

    |-- 50-local.d

    `-- 90-mandatory.d

```

and

```
/var/lib/polkit-1/
`-- localauthority

    |-- 10-vendor.d

    |-- 20-org.d

    |-- 30-site.d

    |-- 50-local.d

    `-- 90-mandatory.d

```

The /etc/polkit-1/localauthority hierarchy is intended for local configuration and the /var/lib/polkit-1/localauthority is intended for 3rd party packages.

Each .pkla file contains one or more authorization entries. If the underlying filesystem supports file monitoring, the Local Authority will reload information whenever .pkla files are added, removed or changed.

Each directory is intended for a specific audience

10-vendor.d

Intended for use by the OS vendor.

20-org.d

Intended for the organization deploying the OS.

30-site.d

Intended for the site deploying the system.

50-local.d

Intended for local usage.

90-mandatory.d

Intended for the organization deploying the OS.

and new directories can be added/removed as needed.

As to regards to the content, each .pkla file is a standard key file and contains key/value pairs in one or more groups with each group representing an authorization entry. A .pkla file MUST be named by using a scheme to ensure that the name is unique, e.g. reverse DNS notation or similar. For example, if the organization is “Acme Corp” needs to modify policy for the product “Frobnicator”, a name like com.acme.frobnicator.pkla would be suitable.

## AUTHORIZATION ENTRY
Each group in a .pkla file must have a name that is unique within the file it belongs to. The following keys are recognized:

Identity

A semi-colon separated list of entries to match identities. Each entry should start with unix-user: or unix-group: to specify whether to match on a UNIX user name or a UNIX group name, and continue with a glob matching the group or user name. Netgroups are supported with the unix-netgroup: prefix, but cannot support glob syntax. Finally, an entry "default" (with no prefix) can be used to specify the default match.

Action

A semi-colon separated list of globs to match action identifiers.

ResultActive

The result to return for subjects in an active local session that matches one or more of the given identities. Allowed values are similar to what can be used in the defaults section of .policy files used to define actions, e.g. yes, no, auth_self, auth_self_keep, auth_admin and auth_admin_keep.

ResultInactive

Like ResultActive but instead applies to subjects in inactive local sessions.

ResultAny

Like ResultActive but instead applies to any subject.

All keys specified above are required except that only at least one of ResultAny, ResultInactive and ResultActive must be present.

## EVALUATION ORDER
The authorization entries discussed above are consulted using the following algorithm.

The authorization entries from all .pkla files are ordered using the following rules. First all the basename of all sub-directories (e.g. 30-site.d) from both the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories are enumerated and sorted (using the C locale). If a name exists in both /etc and /var, the one in /etc takes precedence. Then all .pkla files are read in order from this list of sub-directories. For each .pkla file, authorizations from each file are appended in order resulting in an ordered list of authorization entries.

For example, given the following files

```
/var/lib/polkit-1
└── localauthority

    ├── 10-vendor.d

    │   └── 10-desktop-policy.pkla

    ├── 20-org.d

    ├── 30-site.d

    ├── 50-local.d

    ├── 55-org.my.company.d

    │   └── 10-org.my.company.product.pkla

    └── 90-mandatory.d
/etc/polkit-1
└── localauthority

    ├── 10-vendor.d

    │   └── 01-some-changes-from-a-subvendor.pkla

    ├── 20-org.d

    ├── 30-site.d

    ├── 50-local.d

    ├── 55-org.my.company.d

    │   └── 10-org.my.company.product.pkla

    └── 90-mandatory.d

```

the evaluation order of the .pkla files is:

1. 10-desktop-policy.pkla

2. 01-some-changes-from-a-subvendor.pkla

3. 10-org.my.company.product.pkla (the /var one)

4. 10-org.my.company.product.pkla (the /etc one)

When the list of authorization entries has been calculated, the authorization check can be made. First, the user of the Subject is determined and the groups that the user belongs are looked up.

Then, authorization entries that include the "default" field value in the Identity field are consulted in order. If the authorization entry matches the data from the authorization check, then the authorization result from RequireAny, RequireInactive or RequireActive is used.

Next, for each group identity, all authorization entries that contain a matching group entry are again consulted in the same manner.

Finally, the authorization entries are consulted using the user identity in the same manner.

Note that processing continues even after a match. This allows for so called “negative authorizations”, see the section called “EXAMPLE” for further discussion.

## EXAMPLE
The following .pkla file grants authorization to all users in the staff group for actions matching the glob com.example.awesomeproduct.* provided they are in an active session on the local console:

```
[Normal Staff Permissions]
Identity=unix-group:staff
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=yes

```

If the users homer and grimes are member of the staff group but policy requires that an administrator needs to authenticate every time authorization for any action matching com.example.awesomeproduct.* is required, one would add

```
[Exclude Some Problematic Users]
Identity=unix-user:homer;unix-user:grimes
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=auth_admin

```

and make sure this authorization entry is after the first one.

The following entry modifies the default authorization decision (it is overridden by any entry that matches using unix-user: or unix-group:, but overrides any defaults set by the application author in an .action file):

```
[Disable Access by Default]
Identity=default
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=no

```

## FILES
/etc/polkit-1/localauthority, /var/lib/polkit-1/localauthority

Default directories containing decision configuration files.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others. Adapted by Miloslav Trmač <mitr@redhat.com>.

## SEE ALSO
polkit(8)


pklocalauthority

title: pklocalauthority(8)

summary: polkit Local Authority Compatibility

text:
# pklocalauthority(8)

## NAME
pklocalauthority - polkit Local Authority Compatibility

## DESCRIPTION
The polkit Local Authority no longer exists. Existing configuration files are honored; see pkla-admin-identities(8) and pkla-check-authorization(8) for description of the configuration format.

Unlike the original Local Authority implementation, ReturnValue keys are ignored because polkit(8) no longer supports the functionality.

## SEE ALSO
pkla-admin-identities(8), pkla-check-authorization(8), polkit(8)

## AUTHOR
Miloslav Trmač <mitr@redhat.com>

Author


title: popa3d(8)

summary: Post Office Protocol (POP3) server

text:
# popa3d(8)

## NAME
popa3d - Post Office Protocol (POP3) server

## SYNOPSIS
popa3d [-D] [-V]

## DESCRIPTION
popa3d is a Post Office Protocol version 3 (POP3) server.

A POP3 server operates on local mailboxes on behalf of its remote users. Users can connect at any time to check their mailbox and fetch the mail that has accumulated. The advantage of this "pull" approach is that any user with a simple POP3-capable mail reader program can receive mail, eschewing the need for a full-fledged Mail Transfer Agent (MTA) and a permanent network connection.

Note that POP3 can only be used to retrieve mail, not to send it. To send mail, the SMTP protocol is commonly used.

For access to a mailbox through POP3, the username must be in the password database. Additionally, popa3d does not permit null passwords and will refuse to serve mail for root (UID 0) users.

## OPTIONS
-D

Standalone server mode. In this mode, popa3d will become a daemon, accepting connections on the pop3 port (110/tcp) and forking child processes to handle them. This has lower overhead than starting popa3d from an inetd equivalent (which popa3d assumes by default) and is thus useful on busy servers to reduce load. In this mode popa3d also does quite a few checks to significantly reduce the impact of connection flood attacks.

-V

Print version information and exit.

## COMMANDS
A normal POP3 session progresses through three states: AUTHORIZATION, TRANSACTION, and UPDATE.

After the TCP connection opens, the client must authenticate itself to the server during the AUTHORIZATION state. The following commands are supported in the AUTHORIZATION state (all command names are case-insensitive).

USER name

Authenticate as user name.

PASS string

Authenticate using password string.

QUIT

Quit; do not enter UPDATE state.

When authorization is successful, the server enters the TRANSACTION state. The client can now list and retrieve messages or mark messages for deletion. The following commands are supported in the TRANSACTION state.

DELE msg

Mark message for deletion.

LAST

Show highest message number accessed (obsolete).

LIST [msg]

List message number and size.

NOOP

Do nothing.

QUIT

Quit; enter UPDATE state.

RETR msg

Retrieve message.

RSET

Clear deletion marks.

STAT

Return total number of messages and total size.

TOP msg n

Show top n lines of message body.

UIDL [msg]

List message number and digest.

When the client issues the QUIT command in the TRANSACTION state, the server enters the UPDATE state. All messages that were marked for deletion are now removed. The server then closes the connection.

## BUGS
POP3 transmits passwords in plaintext and thus, if you care about the security of your individual user accounts, should only be used either in trusted networks or tunneled over encrypted channels.

There exist extensions to the protocol that are supposed to fix this problem. popa3d does not support them yet, partly because this isn't going to fully fix the problem. In fact, APOP and the weaker defined SASL mechanisms such as CRAM-MD5 may potentially be even less secure than transmission of plaintext passwords because of the requirement that plaintext equivalents be stored on the server.

## AUTHORS
Solar Designer <solar at openwall.com>

This manual page is based heavily on the one Camiel Dobbelaar wrote for OpenBSD.

## SEE ALSO
Official Internet Protocol Standard STD 53, also known as RFC 1939.

http://www.openwall.com/popa3d/


anvil

package: postfix

title: anvil(8)

text:
# anvil(8)

## NAME
anvil - Postfix session count and request rate control

## SYNOPSIS

```
anvil [generic Postfix daemon options]
```

## DESCRIPTION

The Postfix anvil(8) server maintains statistics about client connection counts or client request rates. This information can be used to defend against clients that hammer a server with either too many simultaneous sessions, or with too many successive requests within a configurable time interval. This server is designed to run under control by the Postfix master(8) server.

In the following text, ident specifies a (service, client) combination. The exact syntax of that information is application-dependent; the anvil(8) server does not care.

## CONNECTION COUNT/RATE CONTROL

```

```

To register a new connection send the following request to the anvil(8) server:

```
    request=connect

    ident=string
```

The anvil(8) server answers with the number of simultaneous connections and the number of connections per unit time for the (service, client) combination specified with ident:

```
    status=0

    count=number

    rate=number
```

To register a disconnect event send the following request to the anvil(8) server:

```
    request=disconnect

    ident=string
```

The anvil(8) server replies with:

```
    status=0
```

## MESSAGE RATE CONTROL

```

```

To register a message delivery request send the following request to the anvil(8) server:

```
    request=message

    ident=string
```

The anvil(8) server answers with the number of message delivery requests per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

## RECIPIENT RATE CONTROL

```

```

To register a recipient request send the following request to the anvil(8) server:

```
    request=recipient

    ident=string
```

The anvil(8) server answers with the number of recipient addresses per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

## TLS SESSION NEGOTIATION RATE CONTROL

```

```

The features described in this section are available with Postfix 2.3 and later.

To register a request for a new (i.e. not cached) TLS session send the following request to the anvil(8) server:

```
    request=newtls

    ident=string
```

The anvil(8) server answers with the number of new TLS session requests per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

To retrieve new TLS session request rate information without updating the counter information, send:

```
    request=newtls_report

    ident=string
```

The anvil(8) server answers with the number of new TLS session requests per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

## AUTH RATE CONTROL

```

```

To register an AUTH request send the following request to the anvil(8) server:

```
    request=auth

    ident=string
```

The anvil(8) server answers with the number of auth requests per unit time for the (service, client) combination specified with ident:

```
    status=0

    rate=number
```

## SECURITY

```

```

The anvil(8) server does not talk to the network or to local users, and can run chrooted at fixed low privilege.

The anvil(8) server maintains an in-memory table with information about recent clients requests. No persistent state is kept because standard system library routines are not sufficiently robust for update-intensive applications.

Although the in-memory state is kept only temporarily, this may require a lot of memory on systems that handle connections from many remote clients. To reduce memory usage, reduce the time unit over which state is kept.

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

Upon exit, and every anvil_status_update_time seconds, the server logs the maximal count and rate values measured, together with (service, client) information and the time of day associated with those events. In order to avoid unnecessary overhead, no measurements are done for activity that isn't concurrency limited or rate limited.

## BUGS

Systems behind network address translating routers or proxies appear to have the same client address and can run into connection count and/or rate limits falsely.

In this preliminary implementation, a count (or rate) limited server process can have only one remote client at a time. If a server process reports multiple simultaneous clients, state is kept only for the last reported client.

The anvil(8) server automatically discards client request information after it expires. To prevent the anvil(8) server from discarding client request rate information too early or too late, a rate limited service should always register connect/disconnect events even when it does not explicitly limit them.

## CONFIGURATION PARAMETERS

```

```

On low-traffic mail systems, changes to main.cf are picked up automatically as anvil(8) processes run for only a limited amount of time. On other mail systems, use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

anvil_rate_time_unit (60s)

The time unit over which client connection rates and other rates are calculated.

anvil_status_update_time (600s)

How frequently the anvil(8) connection and rate limiting server logs peak usage information.

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

max_idle (100s)

The maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.

max_use (100)

The maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

## SEE ALSO

```
smtpd(8), Postfix SMTP server
postconf(5), configuration parameters
master(5), generic daemon options
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
TUNING_README, performance tuning
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## HISTORY

The anvil service is available in Postfix 2.2 and later.

## AUTHOR(S)

```
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```


bounce

title: bounce(8)

text:
# bounce(8)

## NAME
bounce - Postfix delivery status reports

## SYNOPSIS

```
bounce [generic Postfix daemon options]
```

## DESCRIPTION

The bounce(8) daemon maintains per-message log files with delivery status information. Each log file is named after the queue file that it corresponds to, and is kept in a queue subdirectory named after the service name in the master.cf file (either bounce, defer or trace). This program expects to be run from the master(8) process manager.

The bounce(8) daemon processes two types of service requests:

- Append a recipient (non-)delivery status record to a per-message log file.

- Enqueue a delivery status notification message, with a copy of a per-message log file and of the corresponding message. When the delivery status notification message is enqueued successfully, the per-message log file is deleted.

The software does a best notification effort. A non-delivery notification is sent even when the log file or the original message cannot be read.

Optionally, a bounce (defer, trace) client can request that the per-message log file be deleted when the requested operation fails. This is used by clients that cannot retry transactions by themselves, and that depend on retry logic in their own client.

## STANDARDS

```
RFC 822 (ARPA Internet Text Messages)
RFC 2045 (Format of Internet Message Bodies)
RFC 2822 (Internet Message Format)
RFC 3462 (Delivery Status Notifications)
RFC 3464 (Delivery Status Notifications)
RFC 3834 (Auto-Submitted: message header)
RFC 5322 (Internet Message Format)
RFC 6531 (Internationalized SMTP)
RFC 6532 (Internationalized Message Format)
RFC 6533 (Internationalized Delivery Status Notifications)
```

## DIAGNOSTICS

Problems and transactions are logged to syslogd(8) or postlogd(8).

## CONFIGURATION PARAMETERS

```

```

Changes to main.cf are picked up automatically, as bounce(8) processes run for only a limited amount of time. Use the command "postfix reload" to speed up a change.

The text below provides only a parameter summary. See postconf(5) for more details including examples.

2bounce_notice_recipient (postmaster)

The recipient of undeliverable mail that cannot be returned to the sender.

backwards_bounce_logfile_compatibility (yes)

Produce additional bounce(8) logfile records that can be read by Postfix versions before 2.0.

bounce_notice_recipient (postmaster)

The recipient of postmaster notifications with the message headers of mail that Postfix did not deliver and of SMTP conversation transcripts of mail that Postfix did not receive.

bounce_size_limit (50000)

The maximal amount of original message text that is sent in a non-delivery notification.

bounce_template_file (empty)

Pathname of a configuration file with bounce message templates.

config_directory (see 'postconf -d' output)

The default location of the Postfix main.cf and master.cf configuration files.

daemon_timeout (18000s)

How much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.

delay_notice_recipient (postmaster)

The recipient of postmaster notifications with the message headers of mail that cannot be delivered within $delay_warning_time time units.

deliver_lock_attempts (20)

The maximal number of attempts to acquire an exclusive lock on a mailbox file or bounce(8) logfile.

deliver_lock_delay (1s)

The time between attempts to acquire an exclusive lock on a mailbox file or bounce(8) logfile.

ipc_timeout (3600s)

The time limit for sending or receiving information over an internal communication channel.

internal_mail_filter_classes (empty)

What categories of Postfix-generated mail are subject to before-queue content inspection by non_smtpd_milters, header_checks and body_checks.

mail_name (Postfix)

The mail system name that is displayed in Received: headers, in the SMTP greeting banner, and in bounced mail.

max_idle (100s)

The maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.

max_use (100)

The maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.

notify_classes (resource, software)

The list of error classes that are reported to the postmaster.

process_id (read-only)

The process ID of a Postfix command or daemon process.

process_name (read-only)

The process name of a Postfix command or daemon process.

queue_directory (see 'postconf -d' output)

The location of the Postfix top-level queue directory.

syslog_facility (mail)

The syslog facility of Postfix logging.

syslog_name (see 'postconf -d' output)

A prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

Available in Postfix 3.0 and later:

smtputf8_autodetect_classes (sendmail, verify)

Detect that a message requires SMTPUTF8 support for the specified mail origin classes.

Available in Postfix 3.3 and later:

service_name (read-only)

The master.cf service name of a Postfix daemon process.

Available in Postfix 3.6 and later:

enable_threaded_bounces (no)

Enable non-delivery, success, and delay notifications that link to the original message by including a References: and In-Reply-To: header with the original Message-ID value.

Available in Postfix 3.7 and later:

header_from_format (standard)

The format of the Postfix-generated From: header.

## FILES

```
/var/spool/postfix/bounce/* non-delivery records
/var/spool/postfix/defer/* non-delivery records
/var/spool/postfix/trace/* delivery status records
```

## SEE ALSO

```
bounce(5), bounce message template format
qmgr(8), queue manager
postconf(5), configuration parameters
master(5), generic daemon options
master(8), process manager
postlogd(8), Postfix logging
syslogd(8), system logging
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## AUTHOR(S)

```
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA
```