man resmgr (Commandes) - resource manager client

NAME

resmgr - resource manager client

SYNOPSIS

resmgr [-s socket] [-u user] [-t] command ...

DESCRIPTION

The resmgr command is a command line client for the resource manager daemon resmgrd(8). It passes the specified command to the daemon, and prints the response.

COMMANDS

Currently, the resource manager protocol supports the following commands, all of which can be performed from the command line using resmgr:

help
Display the list of available commands.
list [family]
Display the list of devices available to the user.
The optional family argument can be used to specify a resource family. If specified, the listing will include only names from that specific family. In addition, device names will be mapped to that particular name space.
For instance, if the resource class includes the device /dev/cdrom, listing the scsi family would return a corresponding SCSI device specifier such as scsi:0,0,1. (Of course, this assumes that /dev/cdrom uses the SCSI CD driver, and that the user has permission to open the corresponding raw SCSI device).
open"[flags]device
Open the specified device and receive the file descriptor through the socket connection. Optionally, one or more flags can be passed.
The flag -ro tells the server to open the device read-only. Otherwise, the device is opened read-write.
If the device is flagged read-only, but the client tries to open it read-write, access is denied.
The device parameter is usually just the path name of the device that should be opened. However, you can prefix the name with a resource family to request a different interpretation of the device name, such as scsi:/dev/cdrom. This will open the raw SCSI device associated with /dev/cdrom. The device must have the scsi flag set, otherwise the request will be refused. This is useful for scanners and CD writers.
For the convenience of applications that want to open a device based on its SCSI ID, the scsi resource family supports an alternative device notation, which is scsi:[bus,]target,lun.
lock"device
Creates a lock file for the device, and put the PID of the client process into the file. The owner of the PID file is set to the uid of the client process, allowing the application to update the contents of the lock file if it puts itself into the background, for example.
If a conflicting lock exists, access is denied. If a stale lock file is found, the server returns error code 202 (stale lock file). This indicates that the client should perform an unlock call for this device, which will remove the stale lock.
unlock"device
Removes a lock file for the device. If a lock file exists which is neither owned by the uid of the calling application, and which is not a stale lockfile, access is denied. Otherwise the lock file is removed.
login"usertty
Indicates to the resource manager that user logged in on terminal tty. This will cause the resource manager to create a session record for the, and grant the user access to all resource classes whose ACLs he matches.
This command is restricted to the administrator. Usually, the login command is executed by the pam_resmgr module when the user logs in, but you can also use it from the X11 GiveConsole script, for instance.
The syntax of the tty parameter is mostly irrelevant, except that it must be unique. When calling login with a tty name for which a session already exists, the previous session is deleted first. This is intended to increase robustness, when for some reason the logout command was not issued.
logout"tty
This will cause the resource manager to delete any session record for the indicated tty, and decrement the reference count on the user record associated with that session. If this was the last session for the user, all access rights for the user are revoked.
This command is restricted to the administrator. Usually, the logout command is executed by the pam_resmgr module when the user logs in, but you can also use it from the X11 TakeConsole script, for instance.
sessions
This command lists all currently active sessions. It is restricted to the administrator.
grant"userclass
This command grants the indicated user access to the resource class class.
This command is restricted to the administrator. Usually, the grant command is executed by the pam_resmgr module when the user logs in, but you can also use it from the X11 GiveConsole script, for instance.
revoke user [class]
This command revokes a user's access rights to the given class. If no class argument is given, access to all classes is revoked.
this command is restricted to the administrator. It is not very useful, but was added for symmetry with grant.
add device class [flags]
This command adds the specified device to resource class class, optionally setting one or more flags on the entry.
This command is restricted to the administrator. It can be used by a hotplugging daemon to make a device available to local users when attached.
The read-only flag marks the device read-only. Attempts to open the device for writing will be refused.
The scsi flag allows clients to ask for the corresponding raw SCSI device instead of the device itself. This is useful for applications such as CD burners that need to find and open the generic SCSI device corresponding to e.g. /dev/cdrom.
remove device [class]
This command removes the specified device from resource class class. If no class argument is given, the device is removed from all classes.
This command is restricted to the administrator. It can be used by a hotplugging daemon to disable access to a device when it becomes unavailable.

OPTIONS

resmgr understands the following command line options:

-t
By default, resmgr will not include the server's numeric response codes in its output. By using the -t option, you can force resmgr to display the server's response as-is.
-u"user
This option can be used by the root user when he wishes to contact the resource manager as user. This option is mostly for debugging and testing purposes.
-s"socket
specifies the name of the socket on which the resource manager is listening. This option is mostly for debugging and testing purposes.

SEE ALSO

AUTHOR

Olaf Kirch <okir@lst.de>