2005-01-18 Havoc Pennington <hp@redhat.com>

	* rename dbus-daemon-1 to dbus-daemon throughout

1 files changed, 0 insertions, 575 deletions

diff --git a/bus/dbus-daemon-1.1.in b/bus/dbus-daemon-1.1.in
deleted file mode 100644
index c38ca68a..00000000
--- a/bus/dbus-daemon-1.1.in
+++ /dev/null
@@ -1,575 +0,0 @@
-.\" 
-.\" dbus-daemon-1 manual page.
-.\" Copyright (C) 2003 Red Hat, Inc.
-.\"
-.TH dbus-daemon-1 1
-.SH NAME
-dbus-daemon-1 \- Message bus daemon
-.SH SYNOPSIS
-.PP
-.B dbus-daemon-1
-dbus-daemon-1 [\-\-version] [\-\-session] [\-\-system] [\-\-config-file=FILE]
-[\-\-print-address[=DESCRIPTOR]] [\-\-print-pid[=DESCRIPTOR]] [\-\-fork]
-
-.SH DESCRIPTION
-
-\fIdbus-daemon-1\fP is the D-BUS message bus daemon. See
-http://www.freedesktop.org/software/dbus/ for more information about
-the big picture. D-BUS is first a library that provides one-to-one
-communication between any two applications; \fIdbus-daemon-1\fP is an
-application that uses this library to implement a message bus
-daemon. Multiple programs connect to the message bus daemon and can
-exchange messages with one another.
-
-.PP
-There are two standard message bus instances: the systemwide message bus 
-(installed on many systems as the "messagebus" init service) and the 
-per-user-login-session message bus (started each time a user logs in).
-\fIdbus-daemon-1\fP is used for both of these instances, but with 
-a different configuration file.
-
-.PP
-The \-\-session option is equivalent to
-"\-\-config-file=@EXPANDED_SYSCONFDIR@/dbus-1/session.conf" and the \-\-system
-option is equivalent to
-"\-\-config-file=@EXPANDED_SYSCONFDIR@/dbus-1/system.conf". By creating 
-additional configuration files and using the \-\-config-file option,
-additional special-purpose message bus daemons could be created.
-
-.PP
-The systemwide daemon is normally launched by an init script, 
-standardly called simply "messagebus". 
-
-.PP
-The systemwide daemon is largely used for broadcasting system events, 
-such as changes to the printer queue, or adding/removing devices.
-
-.PP
-The per-session daemon is used for various interprocess communication 
-among desktop applications (however, it is not tied to X or the GUI 
-in any way).
-
-.PP
-SIGHUP will cause the D-BUS daemon to PARTIALLY reload its
-configuration file.  Some configuration changes would require kicking
-all apps off the bus; so they will only take effect if you restart the
-daemon. Policy changes should take effect with SIGHUP.
-
-.SH OPTIONS
-The following options are supported:
-.TP
-.I "--config-file=FILE"
-Use the given configuration file.
-.TP
-.I "--fork"
-Force the message bus to fork and become a daemon, even if 
-the configuration file does not specify that it should.
-In most contexts the configuration file already gets this
-right, though.
-.TP
-.I "--print-address[=DESCRIPTOR]"
-Print the address of the message bus to standard output, or 
-to the given file descriptor. This is used by programs that 
-launch the message bus.
-.TP
-.I "--print-pid[=DESCRIPTOR]"
-Print the process ID of the message bus to standard output, or 
-to the given file descriptor. This is used by programs that 
-launch the message bus.
-.TP
-.I "--session"
-Use the standard configuration file for the per-login-session message
-bus.
-.TP
-.I "--system"
-Use the standard configuration file for the systemwide message bus.
-.TP
-.I "--version"
-Print the version of the daemon.
-
-.SH CONFIGURATION FILE
-
-A message bus daemon has a configuration file that specializes it
-for a particular application. For example, one configuration 
-file might set up the message bus to be a systemwide message bus, 
-while another might set it up to be a per-user-login-session bus.
-
-.PP
-The configuration file also establishes resource limits, security
-parameters, and so forth.
-
-.PP
-The configuration file is not part of any interoperability
-specification and its backward compatibility is not guaranteed; this
-document is documentation, not specification.
-
-.PP
-The standard systemwide and per-session message bus setups are
-configured in the files "@EXPANDED_SYSCONFDIR@/dbus-1/system.conf" and
-"@EXPANDED_SYSCONFDIR@/dbus-1/session.conf".  These files normally
-<include> a system-local.conf or session-local.conf; you can put local
-overrides in those files to avoid modifying the primary configuration
-files.
-
-.PP
-The configuration file is an XML document. It must have the following
-doctype declaration:
-.nf
-
-   <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
-    "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
-
-.fi
-
-.PP
-The following elements may be present in the configuration file.
-
-.TP
-.I "<busconfig>"
- 
-.PP
-Root element.
-
-.TP
-.I "<type>"
-
-.PP
-The well-known type of the message bus. Currently known values are
-"system" and "session"; if other values are set, they should be
-either added to the D-BUS specification, or namespaced.  The last
-<type> element "wins" (previous values are ignored).
-
-.PP
-Example: <type>session</type>
-
-.TP
-.I "<include>"
- 
-.PP  
-Include a file <include>filename.conf</include> at this point.  If the
-filename is relative, it is located relative to the configuration file
-doing the including.
-
-.PP
-<include> has an optional attribute "ignore_missing=(yes|no)"
-which defaults to "no" if not provided. This attribute 
-controls whether it's a fatal error for the included file 
-to be absent.
-
-.TP
-.I "<includedir>"
-
-.PP
-Include all files in <includedir>foo.d</includedir> at this
-point. Files in the directory are included in undefined order.
-Only files ending in ".conf" are included.
-
-.PP
-This is intended to allow extension of the system bus by particular
-packages. For example, if CUPS wants to be able to send out
-notification of printer queue changes, it could install a file to
-@EXPANDED_SYSCONFDIR@/dbus-1/system.d that allowed all apps to receive
-this message and allowed the printer daemon user to send it.
-
-.TP
-.I "<user>"
-
-.PP
-The user account the daemon should run as, as either a username or a
-UID. If the daemon cannot change to this UID on startup, it will exit.
-If this element is not present, the daemon will not change or care
-about its UID.
-
-.PP
-The last <user> entry in the file "wins", the others are ignored.
-
-.PP
-The user is changed after the bus has completed initialization.  So
-sockets etc. will be created before changing user, but no data will be
-read from clients before changing user. This means that sockets 
-and PID files can be created in a location that requires root 
-privileges for writing.
-
-.TP
-.I "<fork>"
-    
-.PP
-If present, the bus daemon becomes a real daemon (forks 
-into the background, etc.). This is generally used 
-rather than the \-\-fork command line option.
-
-.TP
-.I "<listen>"
-
-.PP
-Add an address that the bus should listen on. The 
-address is in the standard D-BUS format that contains 
-a transport name plus possible parameters/options.
-
-.PP
-Example: <listen>unix:path=/tmp/foo</listen>
-
-.PP
-If there are multiple <listen> elements, then the bus listens 
-on multiple addresses. The bus will pass its address to 
-started services or other interested parties with 
-the last address given in <listen> first. That is, 
-apps will try to connect to the last <listen> address first.
-
-.TP
-.I "<auth>"
-
-.PP
-Lists permitted authorization mechanisms. If this element doesn't
-exist, then all known mechanisms are allowed.  If there are multiple
-<auth> elements, all the listed mechanisms are allowed.  The order in
-which mechanisms are listed is not meaningful.
-    
-.PP
-Example: <auth>EXTERNAL</auth>
-
-.PP
-Example: <auth>DBUS_COOKIE_SHA1</auth>
-
-.TP
-.I "<servicedir>"
-
-.PP
-Adds a directory to scan for .service files. Directories are
-scanned starting with the last to appear in the config file 
-(the first .service file found that provides a particular 
-service will be used).
-
-.PP
-Service files tell the bus how to automatically start a program.
-They are primarily used with the per-user-session bus, 
-not the systemwide bus.
-
-.TP
-.I "<limit>"
-
-.PP
-<limit> establishes a resource limit. For example:
-.nf
-  <limit name="max_message_size">64</limit>
-  <limit name="max_completed_connections">512</limit>
-.fi
-
-.PP
-The name attribute is mandatory.
-Available limit names are:
-.nf
-      "max_incoming_bytes"         : total size in bytes of messages
-                                     incoming from a single connection
-      "max_outgoing_bytes"         : total size in bytes of messages
-                                     queued up for a single connection
-      "max_message_size"           : max size of a single message in
-                                     bytes
-      "service_start_timeout"      : milliseconds (thousandths) until 
-                                     a started service has to connect
-      "auth_timeout"               : milliseconds (thousandths) a
-                                     connection is given to
-                                     authenticate
-      "max_completed_connections"  : max number of authenticated connections  
-      "max_incomplete_connections" : max number of unauthenticated
-                                     connections
-      "max_connections_per_user"   : max number of completed connections from
-                                     the same user
-      "max_pending_service_starts" : max number of service launches in
-                                     progress at the same time
-      "max_names_per_connection"   : max number of names a single 
-                                     connection can own
-      "max_match_rules_per_connection": max number of match rules for a single 
-                                        connection
-      "max_replies_per_connection" : max number of pending method 
-                                     replies per connection
-                                     (number of calls-in-progress)
-      "reply_timeout"              : milliseconds (thousandths) 
-                                     until a method call times out   
-.fi
-
-.PP
-The max incoming/outgoing queue sizes allow a new message to be queued
-if one byte remains below the max. So you can in fact exceed the max
-by max_message_size.
-
-.PP
-max_completed_connections divided by max_connections_per_user is the
-number of users that can work together to DOS all other users by using
-up all connections.
-
-.TP
-.I "<policy>"
-
-.PP
-The <policy> element defines a policy to be applied to a particular
-set of connections to the bus. A policy is made up of
-<allow> and <deny> elements.
-
-.PP
-The <policy> element has one of three attributes:
-.nf
-  context="(default|mandatory)"
-  user="username or userid"
-  group="group name or gid"
-.fi
-
-.PP
- 
-Policies are applied to a connection as follows:
-.nf
-   - all context="default" policies are applied
-   - all group="connection's user's group" policies are applied
-     in undefined order
-   - all user="connection's auth user" policies are applied
-     in undefined order
-   - all context="mandatory" policies are applied
-.fi
-
-.PP
-Policies applied later will override those applied earlier, 
-when the policies overlap. Multiple policies with the same 
-user/group/context are applied in the order they appear 
-in the config file.
-
-.TP
-.I "<deny>"
-.I "<allow>"
-
-.PP
-A <deny> element appears below a <policy> element and prohibits some
-action. The <allow> element makes an exception to previous <deny>
-statements, and works just like <deny> but with the inverse meaning.
-
-.PP
-The possible attributes of these elements are:
-.nf
-   send_interface="interface_name"
-   send_member="method_or_signal_name" 
-   send_error="error_name" 
-   send_destination="name" 
-   send_type="method_call" | "method_return" | "signal" | "error" 
-   send_path="/path/name"
-
-   receive_interface="interface_name"
-   receive_member="method_or_signal_name" 
-   receive_error="error_name" 
-   receive_sender="name" 
-   receive_type="method_call" | "method_return" | "signal" | "error"
-   receive_path="/path/name"
-
-   send_requested_reply="true" | "false"
-   receive_requested_reply="true" | "false"
-
-   eavesdrop="true" | "false"
-
-   own="name"
-   user="username"
-   group="groupname"
-.fi
-
-.PP
-Examples:
-.nf
-   <deny send_interface="org.freedesktop.System" send_member="Reboot"/> 
-   <deny receive_interface="org.freedesktop.System" receive_member="Reboot"/>
-   <deny own="org.freedesktop.System"/>
-   <deny send_destination="org.freedesktop.System"/>
-   <deny receive_sender="org.freedesktop.System"/>
-   <deny user="john"/>
-   <deny group="enemies"/>
-.fi
-
-.PP
-The <deny> element's attributes determine whether the deny "matches" a
-particular action. If it matches, the action is denied (unless later
-rules in the config file allow it).
-
-.PP
-send_destination and receive_sender rules mean that messages may not be
-sent to or received from the *owner* of the given name, not that
-they may not be sent *to that name*. That is, if a connection
-owns services A, B, C, and sending to A is denied, sending to B or C
-will not work either.
-
-.PP
-The other send_* and receive_* attributes are purely textual/by-value
-matches against the given field in the message header.
-
-.PP
-"Eavesdropping" occurs when an application receives a message that
-was explicitly addressed to a name the application does not own.
-Eavesdropping thus only applies to messages that are addressed to
-services (i.e. it does not apply to signals).
-
-.PP
-For <allow>, eavesdrop="true" indicates that the rule matches even 
-when eavesdropping. eavesdrop="false" is the default and means that 
-the rule only allows messages to go to their specified recipient.
-For <deny>, eavesdrop="true" indicates that the rule matches 
-only when eavesdropping. eavesdrop="false" is the default for <deny>
-also, but here it means that the rule applies always, even when 
-not eavesdropping. The eavesdrop attribute can only be combined with
-receive rules (with receive_* attributes).
-
-
-.PP
-The [send|receive]_requested_reply attribute works similarly to the eavesdrop
-attribute. It controls whether the <deny> or <allow> matches a reply
-that is expected (corresponds to a previous method call message).
-This attribute only makes sense for reply messages (errors and method
-returns), and is ignored for other message types.
-
-.PP
-For <allow>, [send|receive]_requested_reply="true" is the default and indicates that
-only requested replies are allowed by the
-rule. [send|receive]_requested_reply="false" means that the rule allows any reply
-even if unexpected.
-
-.PP
-For <deny>, [send|receive]_requested_reply="false" is the default but indicates that
-the rule matches only when the reply was not
-requested. [send|receive]_requested_reply="true" indicates that the rule applies
-always, regardless of pending reply state.
-
-.PP
-user and group denials mean that the given user or group may 
-not connect to the message bus.
-
-.PP
-For "name", "username", "groupname", etc.
-the character "*" can be substituted, meaning "any." Complex globs
-like "foo.bar.*" aren't allowed for now because they'd be work to
-implement and maybe encourage sloppy security anyway.
-
-.PP
-It does not make sense to deny a user or group inside a <policy>
-for a user or group; user/group denials can only be inside
-context="default" or context="mandatory" policies.
-
-.PP
-A single <deny> rule may specify combinations of attributes such as
-send_destination and send_interface and send_type. In this case, the
-denial applies only if both attributes match the message being denied.
-e.g. <deny send_interface="foo.bar" send_destination="foo.blah"/> would
-deny messages with the given interface AND the given bus name.
-To get an OR effect you specify multiple <deny> rules.
-
-.PP
-You can't include both send_ and receive_ attributes on the same
-rule, since "whether the message can be sent" and "whether it can be
-received" are evaluated separately.
-
-.PP
-Be careful with send_interface/receive_interface, because the 
-interface field in messages is optional.
-
-.TP
-.I "<selinux>"
-
-.PP
-The <selinux> element contains settings related to Security Enhanced Linux.
-More details below.
-
-.TP
-.I "<associate>"
-
-.PP
-An <associate> element appears below an <selinux> element and
-creates a mapping. Right now only one kind of association is possible:
-.nf
-   <associate own="org.freedesktop.Foobar" context="foo_t"/> 
-.fi
-
-.PP
-This means that if a connection asks to own the name
-"org.freedesktop.Foobar" then the source context will be the context
-of the connection and the target context will be "foo_t" - see the 
-short discussion of SELinux below.
-
-.PP
-Note, the context here is the target context when requesting a name,
-NOT the context of the connection owning the name.
-
-.PP
-There's currently no way to set a default for owning any name, if
-we add this syntax it will look like:
-.nf
-   <associate own="*" context="foo_t"/> 
-.fi
-If you find a reason this is useful, let the developers know.
-Right now the default will be the security context of the bus itself.
-
-.PP
-If two <associate> elements specify the same name, the element
-appearing later in the configuration file will be used.
-
-.SH SELinux
-
-.PP
-See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts:
-
-.IP "" 8
-Every subject (process) and object (e.g. file, socket, IPC object,
-etc) in the system is assigned a collection of security attributes,
-known as a security context. A security context contains all of the
-security attributes associated with a particular subject or object
-that are relevant to the security policy.
-
-.IP "" 8
-In order to better encapsulate security contexts and to provide
-greater efficiency, the policy enforcement code of SELinux typically
-handles security identifiers (SIDs) rather than security contexts. A
-SID is an integer that is mapped by the security server to a security
-context at runtime.
-
-.IP "" 8
-When a security decision is required, the policy enforcement code
-passes a pair of SIDs (typically the SID of a subject and the SID of
-an object, but sometimes a pair of subject SIDs or a pair of object
-SIDs), and an object security class to the security server. The object
-security class indicates the kind of object, e.g. a process, a regular
-file, a directory, a TCP socket, etc.
-
-.IP "" 8
-Access decisions specify whether or not a permission is granted for a
-given pair of SIDs and class. Each object class has a set of
-associated permissions defined to control operations on objects with
-that class.
-
-.PP
-D-BUS performs SELinux security checks in two places.
-
-.PP
-First, any time a message is routed from one connection to another
-connection, the bus daemon will check permissions with the security context of
-the first connection as source, security context of the second connection
-as target, object class "dbus" and requested permission "send_msg".
-
-.PP
-If a security context is not available for a connection 
-(impossible when using UNIX domain sockets), then the target 
-context used is the context of the bus daemon itself.
-There is currently no way to change this default, because we're 
-assuming that only UNIX domain sockets will be used to 
-connect to the systemwide bus. If this changes, we'll 
-probably add a way to set the default connection context.
-
-.PP
-Second, any time a connection asks to own a name, 
-the bus daemon will check permissions with the security 
-context of the connection as source, the security context specified
-for the name with an <associate> element as target, object 
-class "dbus" and requested permission "acquire_svc".
-
-.PP
-If the name has no security context associated in the 
-configuration file, the security context of the bus daemon 
-itself will be used.
-
-.SH AUTHOR
-See http://www.freedesktop.org/software/dbus/doc/AUTHORS
-
-.SH BUGS
-Please send bug reports to the D-BUS mailing list or bug tracker,
-see http://www.freedesktop.org/software/dbus/