Software Subscriptions Professional Services Solutions Support and Docs Training About Red Hat
login/logoutbecome a member downloadstorecart
red hat logo
redhat.comredhat network
Red Hat Docs  >  Whitepapers  > 
 

White Paper: Enhanced Console Access


< Prev Contents  

Tinkering

These facilities are extensively customizable. For the pam_console module, the system administrator can define what is considered to be a local system console, which devices are attached to the console, and what the device permissions should be. The pam_xauth module can be told on a per-user basis whether to forward keys.

Disabling program console access
One of the simplest and commonest customizations is to entirely disable all console-equivalent access to programs like shutdown and halt. To do this, run

# rm /etc/security/console.apps/servicename

where servicename is the name of the program to which you wish to disable console-equivalent access. Unless you use xdm, however, be careful not to remove the xserver file, or else no one but root will be able to start the X server. (If you always use xdm to start the X server, root is the only user that needs to start X, in which case you might actually want to remove the xserver file.)

Disabling device mangling
Some users and administrators do not want devices to change ownership or permission at login time. In order to prevent this, you can comment out (or remove) lines like

session    optional     /lib/security/pam_console.so

in files in the /etc/pam.d/ directory.

Defining new device classes
Perhaps a more interesting customization to pam_console is to define a new class of "console devices." Let's say that you use an IDE tape drive and you want to be able to access it from the console without assuming superuser privileges. That means that you want access to the /dev/ht0 and /dev/nht0 files. Here are the steps.

  1. Find the current permissions on the devices:
    $ ls -l /dev/*ht0
    crw-rw---- 1 root disk  37,   0 May 5 1998 /dev/ht0
    crw-rw---- 1 root disk  37, 128 May 5 1998 /dev/nht0
  2. Open the /etc/security/console.perms file in your favorite text editor. The file looks something like this:
    # /etc/security/console.perms
    # ...
    # file classes -- these are regular expressions
    <console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
    
    # device classes -- these are shell-style globs
    <floppy>=/dev/fd[0-1]*
    <sound>=/dev/dsp* /dev/audio* /dev/midi* \
    /dev/mixer* /dev/sequencer
    <cdrom>=/dev/cdrom
    <pilot>=/dev/pilot
    <jaz>=/dev/jaz
    <zip>=/dev/zip
    <fb>=/dev/fb /dev/fb[0-9]*
    <kbd>=/dev/kbd
    <joystick>=/dev/js*
    <v4l>=/dev/video* /dev/radio* /dev/winradio* \
    /dev/vtx* /dev/vbi*
    
    # permission definitions
    <console> 0600 <floppy>    0600 root
    <console> 0600 <sound>     0644 root
    <console> 0600 <cdrom>     0600 root
    <console> 0600 <pilot>     0660 root
    <console> 0600 <jaz>       0660 root
    <console> 0600 <zip>       0660 root
    <console> 0600 <fb>        0600 root
    <console> 0600 <kbd>       0600 root
    <console> 0600 <joystick>  0600 root
    <console> 0600 <v4l>       0600 root
    
  3. At the end of the "device classes" section, add a line like this:
    <idetape>=/dev/*ht0
  4. At the end of the "permission definitions" section, add a line like this:
    <console> 0660 <idetape>   0660 root
  5. Here, 0660 is a file permissions mode; it means readable and writable by both owner and group. The first 0660 specifies the permissions applied to the device when a console user logs in, and the second 0660 specifies the permissions applied when the user logs out. The "root" at the end specifies the user that will own the device when the console user logs out.
  6. Note that these permissions will not take effect until the current console user logs out of all current login sessions and then logs in again.

Redefining the console
You may also redefine the notion of "console." Let's say that you have two machines in close physical proximity, and log into one (which we'll call desktop.example.com) directly and into the other (which we'll call second.example.com) over the network via xdm from the first, so that you have access to two machines on one screen. pam_console will not consider the network login to be a console login, but you might want to change that. On second.example.com, in the file /etc/security/console.perms, you can change the line

<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]

to

<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] \
desktop.example.com:1\.0

(change the 1\.0 to whatever X screen on desktop you normally log in from).

Next, you need to set up your "local" machine (desktop.example.com) to have an X session that queries the "remote" machine via XDMCP. There are two main ways to do this. The first is to use the Xnest X server, and the second is to start a separate X server on the console. The Xnest option is generally a bit nicer. Here is a sample script, which defaults to creating an Xnest window that just barely fits into an empty GNOME desktop with the GNOME panel showing below it. All the customization that you need to do should be to the two variables at the top.

#!/bin/sh

HOST=second.example.com
GEOM=1016x696

while [ -n "$*" ] ; do
case $1 in
-host) shift; HOST=$1; shift; ;;
-geometry) shift; GEOM=$1; shift; ;;
*) echo unknown option "$1" 1>&2; shift; ;;
esac
done

FP=$(echo $(
for i in misc 75dpi Speedo Type1 freefont ; do
[ -f /usr/X11R6/lib/X11/fonts/$i ] && \
echo /usr/X11R6/lib/X11/fonts/$i ;
done) | sed 's/ /,/g')

Xnest :1 -fp $FP -query $HOST -geometry $GEOM &

Alternatively, you can simply run startx -- -query second.example.com :1 causing the next free virtual console (likely virtual console 8, accessed with control-alt-F8; return to your main X session with control-alt-F7) to have a separate X server showing a display from second.example.com.

Allowing console access to new programs
Let's assume that you want to allow anyone at the physical console to be able to reprogram the keyboard, to change the keyboard repeat rate and delay. The /sbin/kbdrate command does precisely that. The steps (which must be performed as root) are as follows:

  1. Create a link in /usr/bin to the consolehelper program.
    # cd /usr/bin
    # ln -s consolehelper kbdrate

    Optionally, if you prefer, you can put the link somewhere else, such as /usr/local/bin:

    # cd /usr/local/bin
    # ln -s /usr/bin/consolehelper kbdrate
  2. Of course, in any case, the directory containing the link must be in the path of any user that wants to use the program. Perhaps less obviously, the directory containing the link must be before /sbin in those users' paths—otherwise the users will run /sbin/kbdrate instead of /usr/bin/kbdrate if they just call kbdrate.
  3. Prepare the PAM configuration. The easiest thing to do is to copy an existing working configuration. If you want the users to be prompted for their own password before allowing them to run kbdrate, do
    # cd /etc/pam.d/
    # cp shutdown kbdrate

    otherwise, do

    # cd /etc/pam.d/
    # cp xserver kbdrate
  4. Enable pam_console authentication for the kbdrate program
    # touch /etc/security/console.apps/kbdrate

Changing pam_xauth settings
Here is a list of changes that users are likely to be interested in making to pam_xauth configuration:

  • A user does not want to export any xauth keys, even to the root account:
    $ touch ~/.xauth/export
  • A system administrator often needs to su from other people's accounts to his/her own account while working within the other users' accounts to fix their problems. The administrator does not want his/her xauth database polluted with extra keys:
    $ touch ~/.xauth/import
  • Bill often helps his friends with their accounts and wants X programs to work when he has used su to assume their accounts, no matter what friend he is helping:
    $ echo '*' > ~/.xauth/export
  • Frank trusts Bill and the root user, but no one else, with his xauth keys:
    $ echo 'root
    bill' > ~/.xauth/export

Further documentation
For more details, there are several man pages you can read:

$ man pam_xauth
$ man 8 pam_console
$ man 5 console.perms
$ man 5 console.apps

< Prev Contents  
 
Product Highlight
 

 
 


 
Copyright © 2002 Red Hat, Inc. All rights reserved. Search by Google
Careers at Red Hat : Legal statement : Privacy statement : Your Account : Contact Red Hat