PowerBroker is a full-featured solution with a rich suite of security
options. Because of these features, PowerBroker can be much more
complicated to set up if all the security options are used. In a strict
comparison with sudo however; using only the features available to
sudo, the installation and maintenance is no more complicated.
Sudo can be an effective solution for organizations where the primary
need is to restrict access for cooperative users and to avoid
errors. If there is a need for a system that will provide an audit trail
and solidly enforce security policy such as is required by HIPAA, SOX,
etc. to prove regulatory compliance, PowerBroker has the built-in
tools to handle that task.
PowerBroker is issued on a per node license which can become costly
for a large scale corporation. The cost is one reason some companies
may not uniformly deploy PowerBroker and may instead use it
as a point solution for mission critical or sensitive data systems.
Symark Power Broker is a commercial package. Sudo is an open source tool.
Courtesy
The graphical user interface on traditional Unix systems, as well as most modern Unix systems other than Mac OS X, is built on the X Window System. One component, the X server, communicates with the hardware (display and input peripherals) and offers basic primitives to display windows and route user input. Other programs, said to be X clients, display windows and listen to user input by communicating with the X server.
In order to talk with the hardware, an X server may require special privileges; for example, on some systems, the X server is setuid root. Recent systems try to avoid having the X server run as root in order to improve security. Depending on the system, running an X server on the system console may be restricted to certain users, or to the user with physical access to the console.
The X server alone does nothing but display a hard-coded background pattern and a mouse cursor. In order to do anything useful, some clients need to be started, typically including a window manager.
The normal way to run a GUI session is to run a session manager program, which takes care of launching all desired clients (window manager, desktop widgets, clipboard manager, restored programs from the user's previous session, etc.). The session manager needs to be started after the X server since it will interact with it. Each desktop environment comes with its own session manager; just about any window manager can also be used as a session manager, and in a pinch a terminal running a shell can be seen as a minimalistic session manager — what matters is that the user has some way to launch the programs they want to run.
There are two traditional ways to launch a GUI session:
- If a user is already logged in, but they don't have a GUI yet, they can run the
xinit
command. This command starts an X server, then starts a session manager, and waits for the session manager to exit; then it kills the X server. This way, the client side of the session and the X server have the same lifetime. The startx
program is a small wrapper around xinit
.
- It's also possible to start a GUI before any user is logged in. In that case, the only client is a display manager, which provides a login prompt. Once a user has logged in, the display manager invokes their session manager. When the session manager exits, the display manager ensures that no more programs are running in that session, and shows a new login prompt.
Another way to see this is that in order to have a graphical login session, there needs to be a graphical interface and the user needs to log in. These two steps can be performed in either order: login then start the GUI (startx
method), or start the GUI then login (display manager method).
Other setups are uncommon but possible. For example, in a kiosk setup, the system startup scripts start an X server and a single full-screen client. In an autologin setup, the display manager runs a session manager for the default user at boot time.
Best Answer
~/.xinitrc
is executed byxinit
, which is usually invoked viastartx
. This program is executed after logging in: first you log in on a text console, then you start the GUI withstartx
. The role of.xinitrc
is to start the GUI part of the session, typically by setting some GUI-related settings such as key bindings (withxmodmap
orxkbcomp
), X resources (withxrdb
), etc., and to launch a session manager or a window manager (possibly as part of a desktop environment).~/.xsession
is executed when you log in in graphical mode (on a display manager) and the display manager invokes the “custom” session type. (With the historical display manager xdm,.xsession
is always executed, but with modern display managers that give the user a choice of session type, you usually need to pick “custom” for.xsession
to run.) Its role is both to set login-time parameters (such as environment variables) and to start the GUI session. A typical.xsession
is~/.xsessionrc
is executed on Debian (and derivatives such as Ubuntu, Linux Mint, etc.) by the X startup scripts on a GUI login, for all session types and (I think) from all display managers. It's also executed fromstartx
if the user doesn't have a.xinitrc
, because in that casestartx
falls back on the same session startup scripts that are used for GUI login. It's executed relatively early, after loading resources but before starting any program such as a key agent, a D-Bus daemon, etc. It typically sets variables that can be used by later startup scripts. It doesn't have any official documentation that I know of, you have to dig into the source to see what works..xinitrc
and.xsession
are historical features of the X11 Window system so they should be available and have a similar behavior on all Unix systems. On the other hand,.xsessionrc
is a Debian feature and distributions that are not based on Debian don't have it unless they've implemented something similar..xprofile
is very similar to.xsessionrc
, but it's part of the session startup script some display managers including GDM (the GNOME display manager) and lightdm, but not others such as xdm and kdm.