title: sane-teco1(5)

text:
# sane-teco1(5)

## NAME
sane-teco1 - SANE backend for TECO / RELISYS scanners

## DESCRIPTION
The sane-teco1 library implements a SANE (Scanner Access Now Easy) backend that provides access to some TECO SCSI flatbed scanners. This backend should be considered beta-quality software! TECO scanners are sold under various brands like RELISYS, PIOTECH, TRUST. This backend may or may not support yours.

The scanners that should work with this backend are:

```
   Vendor Model           TECO model      status
----------------------  --------------  -----------

  Relisys AVEC 2400        VM3520        tested

  Relisys AVEC 2412        VM3520+       tested

  Relisys AVEC 4800        VM4530        untested

  Relisys AVEC 4816        VM4530+       untested

  Relisys RELI 2400        VM3530        untested

  Relisys RELI 2412        VM3530+       tested

  Relisys RELI 2412        VM3530+       untested

  Relisys RELI 4816        VM4540        tested

  Relisys RELI 4830        VM4542        tested

  Relisys RELI 9600        VM6530        untested

  Relisys RELI 9612        VM6530*       untested

  Relisys RELI 9624        VM6530+       untested

  Relisys RELI 9630        VM6540        untested

  Relisys RELI DS15        VM3440        untested

  Relisys RELI DS6         VM3420        untested

  Dextra  DF-600P          VM3510        tested

  Dextra  DF-4830T         VM4542        untested

  Dextra  DF-1200T+        VM3530+       untested

  Dextra  DF-9624          VM6530+       untested
```

Note that the untested scanner will not be directly supported. You should contact the author for that.

The TECO VM number can usually be found at the back of the scanner. It is also part of the FCC ID. sane-find-scanner -v will also show the SCSI inquiry, and if it is a TECO scanner, the name will be there too.

The options the backend supports can either be selected through command line options to programs like scanimage(1) or through GUI elements in xscanimage(1) or xsane(1).

If you have any success with a scanner not listed here, or if you notice any strange behavior, please report to the backend maintainer or to the SANE mailing list.

Valid command line options and their syntax can be listed by using:

scanimage --help -d teco1

Scan Mode

--mode Black & White|Grayscale|Color

Selects the basic mode of operation of the scanner. Valid choices are Black & White, Grayscale and Color. The Black & White mode is for black and white only (1 bit). Grayscale will produce 256 levels of gray (8 bits). Color will produce a 24 bit color image.

--resolution 1..600

Selects the resolution for a scan. The scanner can do all resolutions between 1 and 600, in increments of 1.

Geometry options

-l -t -x -y

Controls the scan area: -l sets the top left x coordinate, -t the top left y coordinate, -x selects the width and -y the height of the scan area. All parameters are specified in millimeters by default.

Enhancement options

--custom-gamma

(color mode only) allows the user to specify a gamma table (see the next 3 parameters).

--red-gamma-table

Can be used to download a user defined gamma table for the red channel. The table must be 256 bytes long. Color mode only.

--green-gamma-table

Can be used to download a user defined gamma table for the green channel. The table must be 256 bytes long. Color mode only.

--blue-gamma-table

Can be used to download a user defined gamma table for the blue channel. The table must be 256 bytes long. Color mode only.

--dither Line art|2x2|3x3|4x4 bayer|4x4 smooth|8x8 bayer|8x8 smooth|8x8 horizontal|8x8 vertical

Select the dither mask to use. Black & White only.

--preview

Requests a preview scan. The resolution used is 22 dpi and the scan area is the maximum allowed. The scan mode is user selected. The default is "no".

## CONFIGURATION FILE
The configuration file /etc/sane.d/teco1.conf supports only one item: the device name to use (eg /dev/scanner).

## FILES
/usr/lib64/sane/libsane-teco1.a

The static library implementing this backend.

/usr/lib64/sane/libsane-teco1.so

The shared library implementing this backend (present on systems that support dynamic loading).

## ENVIRONMENT
SANE_DEBUG_TECO1

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity.

## LIMITATIONS
The windows TWAIN driver has many more options than this SANE backend. However they are only software adjustments. This backend only implements what the scanner can support.

## BUGS
None known.

## SEE ALSO
sane-scsi(5), scanimage(1), xscanimage(1), xsane(1), sane(7)

## AUTHOR
The package is actively maintained by Frank Zago.

http://www.zago.net/sane/#teco

## CREDITS
Thanks to Gerard Delafond for the VM4542 support. Thanks to Jean-Yves Simon for the VM3510 support.


package: libsane

title: sane-teco2(5)

text:
# sane-teco2(5)

## NAME
sane-teco2 - SANE backend for TECO / RELISYS scanners

## DESCRIPTION
The sane-teco2 library implements a SANE (Scanner Access Now Easy) backend that provides access to some TECO SCSI flatbed scanners. This backend should be considered beta-quality software! TECO scanners are sold under various brands like Mustek, Relisys, Piotech, Primax, TRUST. This backend may or may not support yours.

The scanners that should work with this backend are:

```
   Vendor Model               TECO model      status
--------------------------- --------------  -----------

  Mustek ScanMagic 4830S      VM3575         untested

  Primax Jewel 4800           VM356A         good

  Primax Profi 9600           VM6575         basic

  Primax Profi 19200          VM6586         good

  Relisys APOLLO Express 3    VM356A         basic

  Relisys APOLLO Express 6    VM6565         good

  Relisys APOLLO Express 12   ?              untested

  Relisys AVEC II S3          VM3564         good

  Relisys AVEC Super 3        VM3575         basic

  Relisys SCORPIO Pro         VM6575         good

  Relisys SCORPIO Pro-S       VM6586         untested

  Relisys SCORPIO Super 3     VM3575         good
```

For all these scanners, lineart and gray mode work well. However, most of them do not support more than a handful of resolutions in color mode. See the backend home page (under AUTHOR) for the exact status of each scanner.

Note that the untested scanner will not be directly supported. You should contact the author for that.

The TECO VM number can usually be found at the back of the scanner. It is also part of the FCC ID.

The options the backend supports can either be selected through command line options to programs like scanimage(1) or through GUI elements in xscanimage(1), xsane(1), quiteinsane(1) or kooka(1).

If you have any success with a scanner not listed here, or if you notice any strange behavior, please report to the backend maintainer or to the SANE mailing list.

## OPTIONS
Valid command line options and their syntax can be listed by using:

scanimage --help -d teco2

Scan Mode

--mode Lineart|Gray|Color

selects the basic mode of operation of the scanner. The Lineart mode is black and white only (1 bit). Gray mode will produce 256 levels of gray (8 bits). Color will produce a 24 bits color image.

--resolution 1..600

Selects the resolution for a scan. The scanner can do all resolutions between 1 and 600, in increments of 1, for Lineart and Gray. For Color, a restricted set of resolutions are available. Note: All values with ydpi > 300 (300 x 600) or 600 (600 x 1200) result in a wrong proportion for the scan. The proportion can be adjusted with the following convert(1) command from imagemagick:

convert -geometry (dpi/max_xdpi * 100%)x100%

max_xdpi is for the vm3575 constant with 300 dpi e.g. 600dpi adjust with: convert -geometry 200%x100%

--preview

requests a preview scan. The resolution used for that scan is 50 dpi (for VM356A and VM6575 75 dpi) and the scan area is the maximum allowed. The scan mode is user selected. The default is "no".

Geometry options

-l, -t, -x, -y

Control the scan area: -l sets the top left x coordinate, -t the top left y coordinate, -x selects the width and -y the height of the scan area. All parameters are specified in millimeters by default.

Enhancement options

--custom-gamma (no custom gamma option for the VM3564 and VM356A)

(color mode only) allows the user to specify a gamma table (see the next 3 parameters).

## OPTIONS FOR COLOR MODE
These options are valid for scan mode Color only.

--red-gamma-table

Can be used to download a user defined gamma table for the red channel. The table must be 256 bytes long.

--green-gamma-table

Can be used to download a user defined gamma table for the green channel. The table must be 256 bytes long.

--blue-gamma-table

Can be used to download a user defined gamma table for the blue channel. The table must be 256 bytes long.

## OPTIONS ONLY FOR VM3564, VM356A, VM3575 and VM6575
These options are only available for VM3564, VM356A, VM3575 and VM6575 models.

--white-level-r 0..64

Selects what red radiance level should be considered "white", when scanning some sheets by changing the calibration value loaded into the scanner. Scale 0..64 in steps of 1.

--white-level-g 0..64

Selects what green radiance level should be considered "white", when scanning some sheets by changing the calibration value loaded into the scanner. Scale 0..64 in steps of 1.

--white-level-b 0..64

Selects what blue radiance level should be considered "white", when scanning some sheets by changing the calibration value loaded into the scanner. Scale 0..64 in steps of 1.

## CONFIGURATION FILE
The configuration file /etc/sane.d/teco2.conf supports only one item: the device name to use (eg /dev/scanner).

## FILES
/usr/lib64/sane/libsane-teco2.a

The static library implementing this backend.

/usr/lib64/sane/libsane-teco2.so

The shared library implementing this backend (present on systems that support dynamic loading).

## ENVIRONMENT
SANE_DEBUG_TECO2

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity.

SANE_TECO2_CAL_ALGO

Either 0 or 1. Selects the algorithm for the calibration. A value of 1 seems to give better scans on the VM356A, VM3575. Feedback on it is welcome. For VM3564, VM356A, VM3575, VM6575 default 1. For other supported types default 0.

## LIMITATIONS
The windows TWAIN driver has many more options than this SANE backend. However they are only software adjustments. This backend only implements what the scanner can support.

## BUGS
Plenty. Parts of this backend are still under development.

## SEE ALSO
sane(7), sane-scsi(5), scanimage(1), xscanimage(1), xsane(1)

## AUTHORS
Frank Zago

http://www.zago.net/sane/#teco2

The package is actively maintained by Gerard Klaver.

http://gkall.hobby.nl/teco2.html

## CREDITS
Thanks to:

Gerard Klaver for his relentless VM3575 testings and contributed a patch to support the VM3564 and VM356A.

Mark Plowman for providing the first SCSI traces from a VM3575.

Andreas Klaedtke for providing the first SCSI traces from a VM6586 and for his testing, and to Stefan von Dombrowski for his testing.

Nicolas Peyresaubes for providing the first SCSI traces from a VM656A and for his testing.

Dave Parker for testing the support for the VM6575.

Michael Hoeller for testing the support for the VM356A.

Christoph Hoeffner for testing the support for the VM3564 (Relisys AVEC II S3 firmware 1.09).


title: sane-teco3(5)

text:
# sane-teco3(5)

## NAME
sane-teco3 - SANE backend for TECO / RELISYS scanners

## DESCRIPTION
The sane-teco3 library implements a SANE (Scanner Access Now Easy) backend that provides access to some TECO SCSI flatbed scanners. This backend should be considered alpha-quality software! TECO scanners are sold under various brands like RELYSIS, PIOTECH, TRUST. This backend may or may not support yours.

The scanners that should work with this backend are:

```
  Vendor Model                 TECO model   status

  ---------------------------  ----------  ----------

  Relisys Scorpio                VM3552     tested

  Plustek OpticPro 2400SP        VM3552     untested

  PIOTECH Splendeur 3024         VM3552     tested

  Trust Imagery 2400 SP          VM3552     tested

  Trust Imagery 4800 SP+         VM3552     tested

  Trust Imagery 9600 SP          VM3552     untested
```

The TECO VM number can usually be found at the back of the scanner. It is also part of the FCC ID.

The options the backend supports can either be selected through command line options to programs like scanimage(1) or through GUI elements in xscanimage(1) or xsane(1).

If you have any success with a scanner not listed here, or if you notice any strange behavior, please report to the backend maintainer or to the SANE mailing list.

## OPTIONS
Valid command line options and their syntax can be listed by using:

scanimage --help -d teco3

Scan Mode

--mode Black & White|Grayscale|Color

Selects the basic mode of operation of the scanner. The Black & White mode is black and white only (1 bit). Grayscale will produce 256 levels of gray (8 bits). Color will produce a 24-bit color image.

--resolution 1..1200

Selects the resolution for a scan. The scanner can do all resolutions between 1 and 1200, in increments of 1.

--preview

Requests a preview scan. The resolution used for that scan is 22 dpi and the scan area is the maximum allowed. The scan mode is user selected. The default is "no".

Geometry options

-l -t -x -y

Control the scan area: -l sets the top left x coordinate, -t the top left y coordinate, -x selects the width and -y the height of the scan area. All parameters are specified in millimeters by default.

## OPTIONS FOR COLOR MODE ONLY
--custom-gamma

Allows the user to specify a gamma table (see the next 3 parameters).

--red-gamma-table

Can be used to download a user defined gamma table for the red channel. The table must be 1024 bytes long.

--green-gamma-table

Can be used to download a user defined gamma table for the green channel. The table must be 1024 bytes long.

--blue-gamma-table

Can be used to download a user defined gamma table for the blue channel. The table must be 1024 bytes long.

## CONFIGURATION FILE
The configuration file /etc/sane.d/teco3.conf supports only one item: the device name to use (eg /dev/scanner).

## FILES
/usr/lib64/sane/libsane-teco3.a

The static library implementing this backend.

/usr/lib64/sane/libsane-teco3.so

The shared library implementing this backend (present on systems that support dynamic loading).

## ENVIRONMENT
SANE_DEBUG_TECO3

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity.

## LIMITATIONS
The windows TWAIN driver has many more options than this SANE backend. However they are only software adjustments. This backend only implements what the scanner can support.

## BUGS
Not much.

## SEE ALSO
sane-scsi(5), scanimage(1), xscanimage(1), xsane(1), sane(7)

## AUTHOR
The package is actively maintained by Frank Zago.

http://www.zago.net/sane/#teco3


sane-test

title: sane-test(5)

summary: SANE backend for testing frontends

text:
# sane-test(5)

## NAME
sane-test - SANE backend for testing frontends

## DESCRIPTION
The sane-test library implements a SANE (Scanner Access Now Easy) backend that allows testing the SANE installation and SANE frontends. It provides access to a (nearly) unlimited number of virtual devices. There is no support for real scanners or cameras. However, the backend simulates scanning and setting options.

The idea is not only to find bugs in frontends but also to show all capabilities of SANE. Therefore sane-test implements functions and options that are not (or seldom) found in other backends.

The backend is commented out in /etc/sane.d/dll.conf, so either the comment character must be removed or the backend must be called explicitly. E.g. scanimage -d test or xscanimage test.

## SCAN MODE OPTIONS
Option mode selects the scan mode (Gray or Color).

Option depth determines the number of bits per sample (1. 8, or 16). Keep in mind, that this value refers to the sample, not the pixel. So depth=16 results in 48 bits per pixel in color mode. The most usual combinations are mode=Gray, depth=1 for lineart, mode=Gray, depth=8 for gray and mode=Color, depth=8 for color mode. The combination of color and 1-bit mode is quite obscure (8 colors) but allowed in the SANE standard. However, the meaning of bits is not defined. Currently 1 = high intensity and 0 = low intensity is used.

Setting option hand-scanner results in the test-backend behaving like a hand-scanner. Hand-scanners do not know the image height a priori. Instead, they return a height of -1. Setting this option allows one to test whether a frontend can handle this correctly. This option also enables a fixed width of 11 cm.

Setting option three-pass simulates a three-pass scanner. Older color scanners needed to scan the image once per color (red/green/blue) to get the full image. Therefore, in this mode three single frames are transmitted in color mode.

Option three-pass-order provides support for changing the order of the three frames (see option three-pass above). A frontend should support all orders.

Option resolution sets the resolution of the image in dots per inch.

Option source can be used to simulate an Automatic Document Feeder (ADF). After 10 scans, the ADF will be "empty".

## SPECIAL OPTIONS
Option test-picture allows one to set the image that's returned to the frontend. While "Solid white" and "Solid black" are quite obvious, the other options need some more explanation. Color patterns are used to determine if all modes and their colors are represented correctly by the frontend. The grid should look like the same in every mode and resolution. A table of all the test pictures can be found at: http://www.meier-geinitz.de/sane/test-backend/test-pictures.html.

If option invert-endianness is set, the upper and lower bytes of image data in 16 bit modes are exchanged. This option can be used to test the 16 bit modes of frontends, e.g. if the frontend uses the correct endianness.

If option read-limit is set, the maximum amount of data transferred with each call to sane_read() is limited.

Option read-limit-size sets the limit for option read-limit. A low limit slows down scanning. It can be used to detect errors in frontend that occur because of wrong assumptions on the size of the buffer or timing problems.

Option read-delay enables delaying data to the frontend.

Option read-delay-duration selects the number of microseconds the backends waits after each transfer of a buffer. This option is useful to find timing-related bugs, especially if used over the network.

If option read-return-value is different from "Default", the selected status will be returned by every call to sane_read(). This is useful to test the frontend's handling of the SANE statuses.

If option ppl-loss is different from 0, it determines the number of pixels that are "lost" at the end of each line. That means, lines are padded with unused data.

Option fuzzy-parameters selects that fuzzy (inexact) parameters are returned as long as the scan hasn't been started. This option can be used to test if the frontend uses the parameters it got before the start of the scan (which it shouldn't).

Option non-blocking determines if non-blocking IO for sane_read() should be used if supported by the frontend.

If option select-fd is set, the backend offers a select filedescriptor for detecting if sane_read() will return data.

If option enable-test-options is set, a fairly big list of options for testing the various SANE option types is enabled.

Option print-options can be used to print a list of all options to standard error.

## GEOMETRY OPTIONS
Option tl-x determines the top-left x position of the scan area.

Option tl-y determines the top-left y position of the scan area.

Option br-x determines the bottom-right x position of the scan area.

Option br-y determines the bottom-right y position of the scan area.

## BOOL TEST OPTIONS
There are 6 bool test options in total. Each option is numbered. (3/6) means: this is option 3 of 6. The numbering scheme is intended for easier detection of options not displayed by the frontend (because of missing support or bugs).

Option bool-soft-select-soft-detect (1/6) is a bool test option that has soft select and soft detect (and advanced) capabilities. That's just a normal bool option.

Option bool-hard-select-soft-detect (2/6) is a bool test option that has hard select and soft detect (and advanced) capabilities. That means the option can't be set by the frontend but by the user (e.g. by pressing a button at the device).

Option bool-hard-select (3/6) is a bool test option that has hard select (and advanced) capabilities. That means the option can't be set by the frontend but by the user (e.g. by pressing a button at the device) and can't be read by the frontend.

Option bool-soft-detect (4/6) is a bool test option that has soft detect (and advanced) capabilities. That means the option is read-only.

Option bool-soft-select-soft-detect-emulated (5/6) is a Bool test option that has soft select, soft detect, and emulated (and advanced) capabilities.

Option bool-soft-select-soft-detect-auto (6/6) is a Bool test option that has soft select, soft detect, and automatic (and advanced) capabilities. This option can be automatically set by the backend.

## INT TEST OPTIONS
There are 7 int test options in total.

Option int (1/7) is an int test option with no unit and no constraint set.

Option int-constraint-range (2/7) is an int test option with unit pixel and constraint range set. Minimum is 4, maximum 192, and quant is 2.

Option int-constraint-word-list (3/7) is an int test option with unit bits and constraint word list set.

Option int-constraint-array (4/7) is an int test option with unit mm and using an array without constraints.

Option int-constraint-array-constraint-range (5/7) is an int test option with unit mm and using an array with a range constraint. Minimum is 4, maximum 192, and quant is 2.

Option int-constraint-array-constraint-word-list (6/7) is an int test option with unit percent and using an array a word list constraint.

Option int-inexact (7/7) is an int test option that increments the requested value and returns flag SANE_INFO_INEXACT.

## FIXED TEST OPTIONS
There are 3 fixed test options in total.

Option fixed (1/3) is a fixed test option with no unit and no constraint set.

Option fixed-constraint-range (2/3) is a fixed test option with unit microsecond and constraint range set. Minimum is -42.17, maximum 32767.9999, and quant is 2.0.

Option fixed-constraint-word-list (3/3) is a Fixed test option with no unit and constraint word list set.

## STRING TEST OPTIONS
There are 3 string test options in total.

Option string (1/3) is a string test option without constraint.

Option string-constraint-string-list (2/3) is a string test option with string list constraint.

Option string-constraint-long-string-list (3/3) is a string test option with string list constraint. Contains some more entries...

## BUTTON TEST OPTION
Option button (1/1) is a Button test option. Prints some text...

## FILES
/etc/sane.d/test.conf

The backend configuration file (see also description of SANE_CONFIG_DIR below). The initial values of most of the basic SANE options can be configured in this file. A template containing all the default values is provided together with this backend. One of the more interesting values may be number_of_devices. It can be used to check the frontend's ability to show a long list of devices. The config values concerning resolution and geometry can be useful to test the handling of big file sizes.

/usr/lib64/sane/libsane-test.a

The static library implementing this backend.

/usr/lib64/sane/libsane-test.so

The shared library implementing this backend (present on systems that support dynamic loading).

## ENVIRONMENT
SANE_CONFIG_DIR

This environment variable specifies the list of directories that may contain the configuration file. On *NIX systems, the directories are separated by a colon (`:'), under OS/2, they are separated by a semi-colon (`;'). If this variable is not set, the configuration file is searched in two default directories: first, the current working directory (".") and then in /etc/sane.d. If the value of the environment variable ends with the directory separator character, then the default directories are searched after the explicitly specified directories. For example, setting SANE_CONFIG_DIR to "/tmp/config:" would result in directories tmp/config, ., and /etc/sane.d being searched (in this order).

SANE_DEBUG_TEST

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. Higher debug levels increase the verbosity of the output. Example: export SANE_DEBUG_TEST=4

## SEE ALSO
sane(7), scanimage(1), xscanimage(1)

http://www.meier-geinitz.de/sane/test-backend/

## AUTHOR
Henning Meier-Geinitz <henning@meier-geinitz.de>

## BUGS
- config file values aren't tested for correctness


title: sane-u12(5)

text:
# sane-u12(5)

## NAME
sane-u12 - SANE backend for Plustek USB flatbed scanners, based on older parport designs

## DESCRIPTION
The sane-u12 library implements a SANE (Scanner Access Now Easy) backend that provides access to USB flatbed scanners based on Plusteks' ASIC 98003 (parallel-port ASIC) and a GeneSys Logics' USB-parport bridge chip.

## SUPPORTED DEVICES
The backend is able to support some early Plustek USB scanners that based their old parport design around the ASIC 98003 and other rebadged Plustek devices. The following tables will give you a short overview.

If your Plustek scanner has another Product ID, then the device is NOT supported by this backend.

Vendor Plustek - ID: 0x07B3

```
----------------------------------------------------------
Model:                   Vendor-ID:       Product-ID:
----------------------------------------------------------
OpticPro U12             0x07B3           0x0001
OpticPro U1212           0x07B3           0x0001
OpticPro UT12            0x07B3           0x0001
```

Vendor KYE/Genius

```
--------------------------------------------------------
USB Model:               Vendor-ID:       Product-ID:
--------------------------------------------------------
ColorPage Vivid III USB  0x07B3           0x0001
ColorPage HR6 V1         0x0458           0x2004
```

## CONFIGURATION
To use your scanner with this backend, you need at least two entries in the configuration file /etc/sane.d/u12.conf

[usb] vendor-id product-id

device /dev/usbscanner

[usb] tells the backend, that the following devicename (here /dev/usbscanner) has to be interpreted as USB scanner device. If vendor- and product-id has not been specified, the backend tries to detect this by its own. If device is set to auto then the next matching device is used.

The Options:

option warmup t

t specifies the warmup period in seconds

option lampOff t

t is the time in seconds for switching off the lamps in standby mode

option lOffonEnd b

b specifies the behaviour when closing the backend, 1 --> switch lamps off, 0 --> do not change lamp status

See the u12.conf file for examples.

Note: You have to make sure, that the USB subsystem is loaded correctly and you have access to the device-node. For more details see sane-usb(5) manpage. You might use sane-find-scanner(1) to check that you have access to your device.

Note:

If there's no configuration file, the backend defaults to device auto

## FILES
/etc/sane.d/u12.conf

The backend configuration file

/usr/lib64/sane/libsane-u12.a

The static library implementing this backend.

/usr/lib64/sane/libsane-u12.so

The shared library implementing this backend (present on systems that support dynamic loading).

## ENVIRONMENT
SANE_CONFIG_DIR

This environment variable specifies the list of directories that may contain the configuration file. On *NIX systems, the directories are separated by a colon (`:'), under OS/2, they are separated by a semi-colon (`;'). If this variable is not set, the configuration file is searched in two default directories: first, the current working directory (".") and then in /etc/sane.d. If the value of the environment variable ends with the directory separator character, then the default directories are searched after the explicitly specified directories. For example, setting SANE_CONFIG_DIR to "/tmp/config:" would result in directories tmp/config, ., and /etc/sane.d being searched (in this order).

SANE_DEBUG_U12

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. Higher debug levels increase the verbosity of the output. Example: export SANE_DEBUG_U12=10

## SEE ALSO
sane(7), sane-usb(5), sane-plustek(5), sane-find-scanner(1), xscanimage(1), scanimage(1)

/usr/share/doc/sane-backends/u12/U12.changes

## CONTACT AND BUG-REPORTS
Please send any information and bug-reports to:

SANE Mailing List

Additional info and hints can be obtained from our

Mailing-List archive at:

http://www.sane-project.org/mailing-lists.html

To obtain debug messages from the backend, please set the environment-variable SANE_DEBUG_U12 before calling your favorite scan-frontend (i.e. xscanimage(1)), i.e.:

export SANE_DEBUG_U12=20 ; xscanimage

The value controls the verbosity of the backend.

## KNOWN BUGS & RESTRICTIONS
* The driver is in alpha state, so please don't expect too much!!!

* When using libusb, it might be, that the backend hangs. In that case, reconnect the scanner.


sane-umax

title: sane-umax(5)

summary: SANE backend for UMAX scanners

text:
# sane-umax(5)

## NAME
sane-umax - SANE backend for UMAX scanners

## ABOUT THIS FILE
This file is only a brief description of the sane-umax backend for SANE! For detailed information take a look at sane-umax-doc.html (it is included in the sane source directory and in the xsane(1) online help)!

## DESCRIPTION
The sane-umax library implements a SANE backend that provides access to several UMAX-SCSI-scanners and some Linotype Hell SCSI-scanners, parallel- and USB-scanners are not (and probably will never be) supported!

I suggest you hold one hand on the power-button of the scanner while you try the first scans!

## CONFIGURATION
The configuration file for this backend resides in /etc/sane.d/umax.conf.

Its contents is a list of device names that correspond to UMAX and UMAX compatible scanners. Empty lines and lines starting with a hash mark (#) are ignored. A sample configuration file is shown below:

```
 # this is a comment

 #

 option scsi-maxqueue 4

 option scsi-buffer-size-min 65536

 option scsi-buffer-size-max 131072

 option scan-lines 40

 option preview-lines 10

 option scsi-maxqueue 2

 option execute-request-sense 0

 option force-preview-bit-rgb 0

 option slow-speed -1

 option care-about-smearing -1

 option calibration-full-ccd -1

 option calibration-width-offset -1

 option calibration-bytes-pixel -1

 option exposure-time-rgb-bind -1

 option invert-shading-data -1

 option lamp-control-available 0

 option gamma-lsb-padded 0

 /dev/sge

 #scsi Vendor Model Type Bus Channel ID LUN

 # The following scanner supports lamp control

 option lamp-control-available 1

 scsi UMAX * Scanner * * * * *

 # scanner on /dev/scanner does not support lamp control

 option lamp-control-available 0

 /dev/scanner
```

execute-request-sense:

values: 0 = disabled, 1 = enabled

default = 0

If set to 1, umax_do_request_sense() is called in umax_do_calibration(). This can hang the system, but has been enabled until this version.

scsi-buffer-size-min, scsi-buffer-size-max:

values: 4096-1048576

default min = 32768, max = 131072

Especially the minimum value is very important. If this value is set too small the backend is not able to send gamma tables to the scanner or to do a correct color calibration. This may result in strange color effects. If the minimum value is set too large then the backend is not able to allocate the requested SCSI buffer size and aborts with out of memory error. The default is 32KB, for some scanners it should be increased to 64KB.

scan-lines, preview-lines:

values: 1-65535

default: scan-lines = 40, preview-lines = 10

define the maximum number of lines that are scanned into one buffer

force-preview-bit-rgb:

values: 0 = disabled, 1 = enabled

default = 0

set preview bit in rgb real scan

slow-speed, care-about-smearing:

values: -1 = auto, 0 = disabled, 1 = enabled

default = -1

Dangerous options, needed for some scanners.

Do not change these options unless you really know what you are doing otherwise you may destroy your scanner with invalid values.

calibration-full-ccd:

values: -1 = auto, 0 = disabled, 1 = enabled

default = -1

do calibration for each pixel of ccd instead of selected image

calibration-width-offset:

values: -99999 = auto, > -99999 set value

add an offset to the calculated width for image/ccd

calibration-bytes-pixel:

values: -1 = disabled, 0 = not set, 1 = 1 byte/pixel, 2 = 2 bytes/pixel

use # bytes per pixel for calibration

exposure-time-rgb-bind:

values: -1 = automatically set by driver - if known, 0 = disabled (own selection for red, green and blue), 1 = enabled (same values for red, green and blue)

invert-shading-data:

values: -1 = automatically set by driver - if known, 0 = disabled, 1 = enabled

default = -1

invert shading data before sending it back to the scanner

lamp-control-available:

values: 0 = automatically set by driver - if known, 1 = available

default = 0

gamma-lsb-padded:

values: -1 = automatically set by driver - if known, 0 = gamma data is msb padded, 1 = gamma data is lsb padded

default = -1

handle-bad-sense-error:

values: 0 = handle as device busy, 1 = handle as ok, 2 = handle as i/o error, 3 = ignore bad error code - continue sense handler

default = 0

scsi-maxqueue:

values: 1..# (maximum defined at compile time)

default = 2

most SCSI drivers allow internal command queueing with a depth of 2 commands. In most cases it does not improve anything when you increase this value. When your SCSI driver does not support any command queueing you can try to set this value to 1.

The special device name must be a generic SCSI device or a symlink to such a device. To find out to which device your scanner is assigned and how you have to set the permissions of that device, have a look at sane-scsi(5).

## SCSI ADAPTER TIPS
The ISA-SCSI-adapters that are shipped with some UMAX-scanners are not supported very well by Linux (I suggest not to use it), the PCI-SCSI-adapters that come with some UMAX-scanners are not supported at all (as far as I know). On other platforms these SCSI-adapters are not supported. So you typically need to purchase another SCSI-adapter that is supported by your platform. See the relevant hardware FAQs and HOWTOs for your platform for more information.

The UMAX-scanners do block the SCSI-bus for a few seconds while scanning. It is not necessary to connect the scanner to its own SCSI-adapter. But if you need short response time for your SCSI-harddisk (e.g. if your computer is a file-server) or other SCSI devices, I suggest you use an own SCSI-adapter for your UMAX-scanner.

If you have any problems with your UMAX scanner, check your SCSI chain (cable length, termination, ...).

See also: sane-scsi(5)

## FILES
The backend configuration file:

/etc/sane.d/umax.conf

The static library implementing this backend:

/usr/lib64/sane/libsane-umax.a

The shared library implementing this backend:

/usr/lib64/sane/libsane-umax.so (present on systems that support dynamic loading)

## ENVIRONMENT
SANE_DEBUG_UMAX

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity. SANE_DEBUG_UMAX values:

```
Number  Remark

 0       print important errors (printed each time)

 1       print errors

 2       print sense

 3       print warnings

 4       print scanner-inquiry

 5       print information

 6       print less important information

 7       print called procedures

 8       print reader_process messages

 10      print called sane-init-routines

 11      print called sane-procedures

 12      print sane infos

 13      print sane option-control messages
```

Example:

export SANE_DEBUG_UMAX=8

## BUGS
X-resolutions greater than 600 dpi sometimes cause problems.

## SEE ALSO
sane(7), sane-scsi(5)

## AUTHOR
Oliver Rauch

## EMAIL-CONTACT
Oliver.Rauch@Rauch-Domain.DE


title: sane-umax1220u(5)

text:
# sane-umax1220u(5)

## NAME
sane-umax1220u - SANE backend for the UMAX Astra 1220U and similar scanners

## DESCRIPTION
The sane-umax1220 library implements a SANE (Scanner Access Now Easy) backend for the the UMAX Astra 1220U and similar scanners.

For more information on this backend, please visit http://umax1220u-sane.sourceforge.net/.

## UMAX ASTRA 1600U/2000U/2100U SUPPORT
This backend is also able to drive the UMAX Astra 1600U/2000U/2100U. The 2100U is confirmed to work. For the other scanners no reports have been received yet. Please contact us and tell us if your scanner works (sane-devel@alioth-lists.debian.net).

## CONFIGURATION
Usually, no manual configuration is necessary. The configuration file for this backend resides in /etc/sane.d/umax1220u.conf.

Its content is a list of device names that correspond to UMAX Astra scanners. Empty lines and lines starting with a hash mark (#) are ignored. A sample configuration file is shown below:

```
 #usb vendor product

 usb 0x1606 0x0010

 # Device list for non-linux systems

 /dev/scanner

 /dev/usb/scanner0
```

See sane-usb(5) for information on how to set the access permissions on the usb device files.

## FILES
The backend configuration file:

/etc/sane.d/umax1220u.conf

The static library implementing this backend:

/usr/lib64/sane/libsane-umax1220u.a

The shared library implementing this backend:

/usr/lib64/sane/libsane-umax1220u.so (present on systems that support dynamic loading)

## ENVIRONMENT
SANE_DEBUG_UMAX1220U

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity: SANE_DEBUG_UMAX1220U values:

```
Number  Remark

 1       print failures

 2       print information

 3       print high-level function calls

 4       print high-level function checkpoints

 9       print mid-level function calls

 10      print mid-level function checkpoints

 80      print protocol-level function entry

 90      print protocol-level function exit
```

Example:

export SANE_DEBUG_UMAX1220U=10

## KNOWN BUGS
600 dpi scanning may fail for large image sizes.

If you keep getting I/O errors, try cycling the power on your scanner to reset it.

There is no way to cancel a scan, since the driver ignores sane_cancel().

If you try scanning an image which is too small, you will get I/O errors. Be sure to adjust the scan area before doing a scan, since by default, the scan area is zero.

## SEE ALSO
sane(7), sane-usb(5)

(Old) homepage:

http://umax1220u-sane.sourceforge.net/

## AUTHOR
Marcio Luis Teixeira <marciot@users.sourceforge.net>

## EMAIL-CONTACT
sane-devel@alioth-lists.debian.net

## REPORTING BUGS
This backend isn't actively maintained. Nevertheless, bug reports and comments should be sent to the sane-devel mailing list. When reporting bugs, please run the backend with SANE_DEBUG_UMAX1220U set to 10 and attach a copy of the log messages.


title: sane-umax_pp(5)

text:
# sane-umax_pp(5)

## NAME
sane-umax_pp - SANE backend for Umax Astra parallel port flatbed scanners

## DESCRIPTION
The sane-umax_pp library implements a SANE (Scanner Access Now Easy) backend that provides access to Umax parallel port flatbed scanners. The following scanners work with this backend:

Model:

--------------------

Astra 610P

Astra 1220P

HP3200C

Astra 1600P

Astra 2000P

Genius ColorPage-Life Pro

This backend handles 75x75, 150x150, 300x300, 600x600 and 600x1200 for 1220P/1600P/2000P dpi scan resolutions, and 75x75, 150x150, 300x300 and 300x600 for 610P. In color and gray levels, there is a software lineart mode.

The new generation models share a newer version of the 610P ASIC embedded in an EPAT chip. Only parts such as CCD and ADC change from one to another. They even all reports being UMAX Astra 1220P via IEEE1284. There isn't a software method to recognize them properly. Under windows, model is set by the driver installed, regardless of the hardware.

EPP/ECP MODES ONLY

The current version of the backend uses only EPP or ECP mode to communicate with the scanner. PS/2 mode isn't implemented. The 610P only use SPP. It is recommended that you set your parallel port to EPP in BIOS with the current version of this backend. You can leave it to ECP or ECP+EPP, but in this case you may not use ppdev but only direct hardware access if you have to use ECP. ECPEPP will only work if you use a 2.4 or 2.6 kernel with ppdev character device support.

This backend does support parport sharing only if you have a kernel with ppdev support.

Note that if you don't use the ppdev character device, the backend needs to run as root. To allow user access to the scanner run the backend through the network interface (See saned(8) and sane-net(5)). A more relaxed solution (security wise) is to add suid bit to the frontend (See chmod(1)). The backend drop root privileges as soon as it can, right after gaining direct access to IO ports, which lessen risks when being root.

## DEVICE NAMES
This backend expects device names of the form:

port value

Where value is :

auto

autodetect all parallel ports and probe them for scanner

safe-auto

autodetect all parallel ports and probe them for scanner, but does not try direct hardware access

/dev/ppi0

uses *BSD ppi device, depending on the number of available parallel port, you have to use /dev/ppi1, /dev/ppi2, ...

/dev/parport0

uses Linux ppdev device, depending on the number of available parallel port, you have to use /dev/parport1, /dev/parport2, ...

0x378

does direct hardware access on the given address. Usual values are 0x378, 0x278, 0x3BC In this case, you have to run the scanner as root (*BSD and Linux), or with 'IOPL=yes' on OS/2

NOTE: in all cases, you must have sufficient privileges to get access to the chosen device or address. Depending on the security settings, devices may not be available for all users. You have to change permissions on the /dev/ppi* or /dev/parport* devices.

You can rename any device using the

name devname

model model

vendor vendor

options. These options apply to the last port option.

## CONFIGURATION
Please make sure to edit umax_pp.conf before you use the backend.

The contents of the umax_pp.conf file is a list of options and device names that correspond to Umax scanners. Empty lines and lines starting with a hash mark (#) are ignored.

The eight options supported are red-gain, green-gain, blue-gain, red-offset, green-offset, blue-offset, astra, and buffer.

Options red-gain, green-gain and blue-gain allow you to adjust the sensitivity of your scanner for the given color. Values range from 0 (lowest gain) to 15 (highest). If the advanced option "Gain" isn't checked in the frontend, the backend does automatic gain calibration, and do not use user provided values.

Options red-offset , green-offset and blue-offset allow you to adjust the offset of your scanner for the given color. Values range from 0 (lowest offset) to 15 (highest).

Option astra allows you to change the model of your scanner. Current auto detection is based on side effects on scanning when using 1220P command set on other models, so it may fail on unknown hardware combination. Valid values are 610, 1220, 1600 and 2000. It is useful only when autodetection fails to detect properly your scanner model. If your scanner work properly but is reported wrongly, let it be that way. The only valid case to change the model is when your scanner produces "black" or "inverted" scans. In this case you can put the model. Be aware that it will prevent scanner model autodetection.

Option buffer allows you to change the size of the scan buffer. The size must be specified in bytes. The default value is 2 megabytes. Decreasing this value will improve the smoothness of progress bar in the frontend, but will stall the scan more often.

## FILES
/etc/sane.d/umax_pp.conf

The backend configuration file (see also description of SANE_CONFIG_DIR below).

/usr/lib64/sane/libsane-umax_pp.a

The static library implementing this backend.

/usr/lib64/sane/libsane-umax_pp.so

The shared library implementing this backend (present on systems that support dynamic loading).

## ENVIRONMENT
SANE_CONFIG_DIR

This environment variable specifies the list of directories that may contain the configuration file. On *NIX systems, the directories are separated by a colon (`:'), under OS/2, they are separated by a semi-colon (`;'). If this variable is not set, the configuration file is searched in two default directories: first, the current working directory (".") and then in /etc/sane.d. If the value of the environment variable ends with the directory separator character, then the default directories are searched after the explicitly specified directories. For example, setting SANE_CONFIG_DIR to "/tmp/config:" would result in directories tmp/config, ., and /etc/sane.d being searched (in this order).

SANE_DEBUG_UMAX_PP

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity.

```
level   debug output
------- ------------------------------

 0       nothing

 1       errors

 2       warnings & minor errors

 3       additional information

 4       debug information

 5       code flow (not supported yet)

 6       special debug information
```

SANE_DEBUG_UMAX_PP_LOW

This variable sets the debug level for the SANE interface for the Umax ASIC. Note that enabling this will spam your terminal with some million lines of debug output.

```
level   debug output
------- -------------------------------

 0       nothing

 1       errors

 8       command blocks

 16      detailed code flow

 32      dump datafiles

 255     everything
```

## SEE ALSO
sane(7), sane-net(5), saned(8)

For latest bug fixes and information see

http://umax1220p.sourceforge.net/

## AUTHOR
Stéphane Voltz <stef.dev@free.fr>

## CREDITS
Support for the 610P has been made possible thank to an hardware donation by William Stuart.

## BUG REPORTS
If something doesn't work, please contact me. But I need some information about your scanner to be able to help you...

SANE version

Run scanimage -V to determine this

the backend version and your scanner hardware

Run SANE_DEBUG_UMAX_PP=255 scanimage -L 2>log as root. If you don't get any output from the sane-umax_pp backend, make sure a line "umax_pp" is included into your /etc/sane.d/dll.conf file. If your scanner isn't detected, make sure you've defined the right port address, or the correct device in your umax_pp.conf file.

the name of your scanner/vendor

also a worthy information. Please also include the optical resolution and lamp type of your scanner, both can be found in the manual of your scanner.

any further comments

if you have comments about the documentation (what could be done better), or you think I should know something, please include it.


sane-usb

title: sane-usb(5)

summary: USB configuration tips for SANE

text:
# sane-usb(5)

## NAME
sane-usb - USB configuration tips for SANE

## DESCRIPTION
This manual page contains information on how to access scanners with a USB interface. It focuses on two main topics: getting the scanner detected by the operating system kernel and using it with SANE.

This page applies to USB most backends and scanners, as they use the generic sanei_usb interface. However, there is one exception: USB Scanners supported by the sane-microtek2(5) backend need a special USB kernel driver.

## QUICK START
This is a short HOWTO-like section. For the full details, read the following sections. The goal of this section is to get the scanner detected by sane-find-scanner(1).

Run sane-find-scanner(1). If it lists your scanner with the correct vendor and product ids, you are done. See section SANE ISSUES for details on how to go on.

sane-find-scanner(1) doesn't list your scanner? Does it work as root? If yes, there is a permission issue. See the LIBUSB section for details.

Nothing is found even as root? Check that your kernel supports USB and that libusb is installed (see section LIBUSB).

## USB ACCESS METHODS
For accessing USB devices, the USB library libusb is used. There used to exist another method to access USB devices: the kernel scanner driver. The kernel scanner driver method is deprecated and shouldn't be used anymore. It may be removed from SANE at any time. In Linux, the kernel scanner driver has been removed in the 2.6.* kernel series. Only libusb access is documented in this manual page.

## LIBUSB
SANE can only use libusb 0.1.6 or newer. It needs to be installed at build-time. Modern Linux distributions and other operating systems come with libusb.

Libusb can only access your scanner if it's not claimed by the kernel scanner driver. If you want to use libusb, unload the kernel driver (e.g. rmmod scanner under Linux) or disable the driver when compiling a new kernel. For Linux, your kernel needs support for the USB filesystem (usbfs). For kernels older than 2.4.19, replace "usbfs" with "usbdevfs" because the name has changed. This filesystem must be mounted. That's done automatically at boot time, if /etc/fstab contains a line like this:

none /proc/bus/usb usbfs defaults 0 0

The permissions for the device files used by libusb must be adjusted for user access. Otherwise only root can use SANE devices. For Linux, the devices are located in /proc/bus/usb/ or in /dev/bus/usb, if you use udev. There are directories named e.g. "001" (the bus name) containing files "001", "002" etc. (the device files). The right device files can be found out by running: scanimage -L: as root. Setting permissions with chmod(1) is not permanent, however. They will be reset after reboot or replugging the scanner.

Usually udev(7) or for older distributions the hotplug utilities are used, which support dynamic setting of access permissions. SANE comes with udev and hotplug scripts in the directory tools/udev and tools/hotplug. They can be used for setting permissions, see /usr/share/doc/sane-backends/README.linux, tools/README and the README in the tools/hotplug directory for more details.

For the BSDs, the device files used by libusb are named /dev/ugen*. Use chmod to apply appropriate permissions.

## SANE ISSUES
This section assumes that your scanner is detected by sane-find-scanner(1). It doesn't make sense to go on, if this is not the case. While sane-find-scanner(1) is able to detect any USB scanner, actual scanning will only work if the scanner is supported by a SANE backend. Information on the level of support can be found on the SANE webpage (http://www.sane-project.org/), and the individual backend manpages.

Most backends can detect USB scanners automatically using "usb" configuration file lines. This method allows one to identify scanners by the USB vendor and product numbers. The syntax for specifying a scanner this way is:

usb VENDOR PRODUCT

where VENDOR is the USB vendor id, and PRODUCT is the USB product id of the scanner. Both ids are non-negative integer numbers in decimal or hexadecimal format. The correct values for these fields can be found by running sane-find-scanner(1), looking into the syslog (e.g., /var/log/messages) or under Linux by issuing the command cat /proc/bus/usb/devices. This is an example of a config file line:

usb 0x055f 0x0006

would have the effect that all USB devices in the system with a vendor id of 0x55f and a product id of 0x0006 would be probed and recognized by the backend.

If your scanner is not detected automatically, it may be necessary to edit the appropriate backend configuration file before using SANE for the first time. For a detailed description of each backend's configuration file, please refer to the relevant backend manual page (e.g. sane-mustek_usb(5) for Mustek USB scanners).

Do not create a symlink from /dev/scanner to the USB device because this link is used by the SCSI backends. The scanner may be confused if it receives SCSI commands.

## ENVIRONMENT
SANE_DEBUG_SANEI_USB

If the library was compiled with debug support enabled, this environment variable controls the debug level for the USB I/O subsystem. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity. Values greater than 4 enable libusb debugging (if available). Example: export SANE_DEBUG_SANEI_USB=4.

SANE_USB_WORKAROUND

If your scanner does not work when plugged into a USB3 port, try setting the environment variable SANE_USB_WORKAROUND to 1. This may work around issues which happen with particular kernel versions. Example: export SANE_USB_WORKAROUND=1.

## SEE ALSO
sane(7), sane-find-scanner(1), sane-"backendname"(5), sane-scsi(5)

## AUTHOR
Henning Meier-Geinitz <henning@meier-geinitz.de>


title: sane-v4l(5)

summary: SANE interface for Video for Linux API

text:
# sane-v4l(5)

## NAME
sane-v4l - SANE interface for Video for Linux API

## DESCRIPTION
The sane-v4l library implements a SANE (Scanner Access Now Easy) backend that provides generic access to video cameras and similar equipment using the V4L (Video for Linux) API.

This is ALPHA software. Really! Important features are missing and there are lots of bugs. The code is currently only tested on a Linux 2.4 system with a Hauppauge WinTV video card.

## DEVICE NAMES
This backend expects device names of the form:

special

Where special is the UNIX path-name for the special device that corresponds to the v4l device. The special device name must be a v4l device or a symlink to such a device. For example, such a device name could be /dev/video0 or /dev/bttv0.

## CONFIGURATION
The contents of the v4l.conf file is a list of device names that correspond to v4l devices. Empty lines and lines starting with a hash mark (#) are ignored. A sample configuration file is shown below:

/dev/bttv0

\# this is a comment

/dev/video3

## FILES
/etc/sane.d/v4l.conf

The backend configuration file (see also description of SANE_CONFIG_DIR below).

/usr/lib64/sane/libsane-v4l.a

The static library implementing this backend.

/usr/lib64/sane/libsane-v4l.so

The shared library implementing this backend (present on systems that support dynamic loading).

## ENVIRONMENT
SANE_CONFIG_DIR

This environment variable specifies the list of directories that may contain the configuration file. On *NIX systems, the directories are separated by a colon (`:'), under OS/2, they are separated by a semi-colon (`;'). If this variable is not set, the configuration file is searched in two default directories: first, the current working directory (".") and then in /etc/sane.d. If the value of the environment variable ends with the directory separator character, then the default directories are searched after the explicitly specified directories. For example, setting SANE_CONFIG_DIR to "/tmp/config:" would result in directories tmp/config, ., and /etc/sane.d being searched (in this order).

SANE_DEBUG_V4L

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. E.g., a value of 128 requests all debug output to be printed. Smaller levels reduce verbosity.

## AUTHOR
Juergen G. Schimmer, Henning Meier-Geinitz

## BUGS:
If more than one video card is present, a crash may occur. Frequency and geometry selection is missing.

Send bug reports to the SANE mailing list: sane-devel@alioth-lists.debian.net. You must be subscribed to the list to send mail. See http://www.sane-project.org/mailing-lists.html for details.

## SEE ALSO
sane(7), xcam(1)


title: sane-xerox_mfp(5)

text:
# sane-xerox_mfp(5)

## NAME
sane-xerox_mfp - SANE backend for Xerox Phaser 3200MFP device et al.

## DESCRIPTION
The sane-xerox_mfp library implements a SANE (Scanner Access Now Easy) backend that provides access to several Samsung-based Samsung, Xerox, and Dell scanners. Please see full list of supported devices at http://www.sane-project.org/sane-supported-devices.html.

## CONFIGURATION
/etc/sane.d/xerox_mfp.conf

USB scanners do not need any configuration. For SCX-4500W in network mode you need to specify

tcp host_address [port]

The host_address is passed through resolver, thus can be a dotted quad or a name from /etc/hosts or resolvable through DNS.

## FILES
/etc/sane.d/xerox_mfp.conf

The backend configuration file. By default all scanner types/models are enabled, you may want to comment out unwanted entries.

/usr/lib64/sane/libsane-xerox_mfp.a

The static library implementing this backend.

/usr/lib64/sane/libsane-xerox_mfp.so

The shared library implementing this backend (present on systems that support dynamic loading).

## ENVIRONMENT
SANE_DEBUG_XEROX_MFP

If the library was compiled with debug support enabled, this environment variable controls the debug level for this backend. Higher debug levels increase the verbosity of the output. Example: export SANE_DEBUG_XEROX_MFP=4

## LIMITATIONS
Multicast autoconfiguration for LAN scanners is not implemented yet. IPv6 addressing has never been tested.

## BUGS AND SUPPORT
If you have found a bug or need support please follow open-source way of acquiring support via mail-lists http://www.sane-project.org/mailing-lists.html or SANE bug tracker http://www.sane-project.org/bugs.html.

## AUTHORS
Alex Belkin <abc@telekom.ru>.

Samsung SCX-4500W scan over network support by Alexander Kuznetsov <acca(at)cpan.org>.

Color scanning on Samsung M2870 model and Xerox Cognac 3215 & 3225 models by Laxmeesh Onkar Markod <m.laxmeesh@samsung.com>.

## SEE ALSO
sane(7), sane-usb(5)


package: libselinux-utils

title: customizable_types(5)

text:
# customizable_types(5)

## NAME
customizable_types - The SELinux customizable types configuration file

## DESCRIPTION
The customizable_types file contains a list of types that can be customised in some way by SELinux-aware applications.

Generally this is a file context type that is usually set on files that need to be shared among certain domains and where the administrator wants to manually manage the type.

The use of customizable types is deprecated as the preferred approach is to use semanage(8) fcontext(8) ...(8). However, SELinux-aware applications such as setfiles(8) will use this information to obtain a list of types relating to files that should not be relabeled.

selinux_customizable_types_path(3) will return the active policy path to this file. The default customizable types file is:

/etc/selinux/{SELINUXTYPE}/contexts/customizable_types

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

is_context_customizable(3) reads this file to determine if a context is customisable or not for the active policy.

## FILE FORMAT
Each line in the file consists of the following:

type

Where:

type The type defined in the policy that can be customised.

## EXAMPLE
\# ./contexts/customizable_types

mount_loopback_t

public_content_rw_t

public_content_t

swapfile_t

sysadm_untrusted_content_t

## SEE ALSO
selinux(8), selinux_customizable_types_path(3), is_context_customizable(3), semanage(8), setfiles(8), selinux_config(5)


title: default_contexts(5)

text:
# default_contexts(5)

## NAME
default_contexts - The SELinux default contexts configuration file

## DESCRIPTION
The default contexts configuration file default_contexts contains entries that allow SELinux-aware login applications such as PAM(8)

SELinux-aware login applications generally use one or more of the following libselinux functions that read these files from the active policy path:

get_default_context(3)

get_ordered_context_list(3)

get_ordered_context_list_with_level(3)

get_default_context_with_level(3)

get_default_context_with_role(3)

get_default_context_with_rolelevel(3)

query_user_context(3)

manual_user_enter_context(3)

The default context configuration file path for the active policy is returned by selinux_default_contexts_path(3). The default, default contexts file is:

/etc/selinux/{SELINUXTYPE}/contexts/default_contexts

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

## FILE FORMAT
Each line in the default configuration file consists of the following:

login_process user_login_process [user_login_process] ...

Where:

login_process This consists of a role:type[:range] entry that represents the login process context that are defined in the policy.

user_login_process This consists of one or more role:type[:range] entries that represent the user login process context defined in the policy.

## EXAMPLE
\# ./contexts/default_contexts

system_r:crond_t:s0 system_r:system_crond_t:s0

system_r:local_login_t:s0 user_r:user_t:s0 staff_r:staff_t:s0

system_r:remote_login_t:s0 user_r:user_t:s0

system_r:sshd_t:s0 user_r:user_t:s0

system_r:sulogin_t:s0 sysadm_r:sysadm_t:s0

system_r:xdm_t:s0 user_r:user_t:s0

## SEE ALSO
selinux(8), selinux_default_contexts_path(3), PAM(8), selinux_default_type_path(3), get_default_context(3), get_ordered_context_list(3), get_ordered_context_list_with_level(3), get_default_context_with_level(3), get_default_context_with_role(3), get_default_context_with_rolelevel(3), query_user_context(3), manual_user_enter_context(3), selinux_config(5)


title: default_type(5)

text:
# default_type(5)

## NAME
default_type - The SELinux default type configuration file

## DESCRIPTION
The default_type file contains entries that allow SELinux-aware applications such as newrole(1) to select a default type for a role if one is not supplied.

selinux_default_type_path(3) will return the active policy path to this file. The default, default type file is:

/etc/selinux/{SELINUXTYPE}/contexts/default_type

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

get_default_type(3) reads this file to determine a type for the active policy.

## FILE FORMAT
Each line within the default_type file is formatted with role:type entries where:

role The SELinux role.

type The domain type that is returned for this role.

## EXAMPLE
\# ./contexts/default_type

auditadm_r:auditadm_t

user_r:user_t

## SEE ALSO
selinux(8), get_default_type(3), newrole(1), selinux_default_type_path(3), selinux_config(5)


title: failsafe_context(5)

text:
# failsafe_context(5)

## NAME
failsafe_context - The SELinux fail safe context configuration file

## DESCRIPTION
The failsafe_context file allows SELinux-aware applications such as PAM(8) to obtain a known valid login context for an administrator if no valid default entries can be found elsewhere.

selinux_failsafe_context_path(3) will return the active policy path to this file. The default failsafe context file is:

/etc/selinux/{SELINUXTYPE}/contexts/failsafe_context

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

The following functions read this file from the active policy path if they cannot obtain a default context:

get_default_context(3)

get_ordered_context_list(3)

get_ordered_context_list_with_level(3)

get_default_context_with_level(3)

get_default_context_with_role(3)

get_default_context_with_rolelevel(3)

query_user_context(3)

manual_user_enter_context(3)

## FILE FORMAT
The file consists of a single line entry as follows:

role:type[:range]

Where:

role type range A role, type and optional range (for MCS/MLS), separated by colons (:) to form a valid login process context for an administrator to access the system.

## EXAMPLE
\# ./contexts/failsafe_context

unconfined_r:unconfined_t:s0

## SEE ALSO
selinux(8), selinux_failsafe_context_path(3), PAM(8), selinux_default_type_path(3), get_default_context(3), get_ordered_context_list(3), get_ordered_context_list_with_level(3), get_default_context_with_level(3), get_default_context_with_role(3), get_default_context_with_rolelevel(3), query_user_context(3), manual_user_enter_context(3), selinux_config(5)


title: removable_context(5)

text:
# removable_context(5)

## NAME
removable_context - The SELinux removable devices context configuration file

## DESCRIPTION
This file contains the default label that should be used for removable devices.

selinux_removable_context_path(3) will return the active policy path to this file. The default removable context file is:

/etc/selinux/{SELINUXTYPE}/contexts/removable_context

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

## FILE FORMAT
The file consists of a single line entry as follows:

user:role:type[:range]

Where:

user role type range A user, role, type and optional range (for MCS/MLS) separated by colons (:) that will be applied to removable devices.

## EXAMPLE
\# ./contexts/removable_contexts

system_u:object_r:removable_t:s0

## SEE ALSO
selinux(8), selinux_removable_context_path(3), selinux_config(5)


secolor.conf

title: secolor.conf(5)

summary: The SELinux color configuration file

text:
# secolor.conf(5)

## NAME
secolor.conf - The SELinux color configuration file

## DESCRIPTION
This optional file controls the color to be associated to the context components associated to the raw context passed by selinux_raw_context_to_color(3), when context related information is to be displayed in color by an SELinux-aware application.

selinux_raw_context_to_color(3) obtains this color information from the active policy secolor.conf file as returned by selinux_colors_path(3).

## FILE FORMAT
The file format is as follows:

color color_name = #color_mask

[...] context_component string = fg_color_name bg_color_name

[...]

Where:

color

The color keyword. Each color entry is on a new line.

color_name A single word name for the color (e.g. red).

color_mask A color mask starting with a hash (#) that describes the hexadecimal RGB colors with black being #000000 and white being #ffffff.

context_component The context component name that must be one of the following:

user, role, type or range

Each context_component string ... entry is on a new line.

string This is the context_component string that will be matched with the raw context component passed by selinux_raw_context_to_color(3).

A wildcard '*' may be used to match any undefined string for the user, role and type context_component entries only.

fg_color_name

The color_name string that will be used as the foreground color. A color_mask may also be used.

bg_color_name The color_name string that will be used as the background color. A color_mask may also be used.

## EXAMPLES
Example 1 entries are:

color black = #000000

color green = #008000

color yellow = #ffff00

color blue = #0000ff

color white = #ffffff

color red = #ff0000

color orange = #ffa500

color tan = #D2B48C user * = black white

role * = white black

type * = tan orange

range s0-s0:c0.c1023 = black green

range s1-s1:c0.c1023 = white green

range s3-s3:c0.c1023 = black tan

range s5-s5:c0.c1023 = white blue

range s7-s7:c0.c1023 = black red

range s9-s9:c0.c1023 = black orange

range s15-s15:c0.c1023 = black yellow

Example 2 entries are:

color black = #000000

color green = #008000

color yellow = #ffff00

color blue = #0000ff

color white = #ffffff

color red = #ff0000

color orange = #ffa500

color tan = #d2b48c user unconfined_u = #ff0000 green

role unconfined_r = red #ffffff

type unconfined_t = red orange

user user_u = black green

role user_r = white black

type user_t = tan red

user xguest_u = black yellow

role xguest_r = black red

type xguest_t = black green

user sysadm_u = white black

range s0-s0:c0.c1023 = black white

user * = black white

role * = black white

type * = black white

## SEE ALSO
selinux(8), selinux_raw_context_to_color(3), selinux_colors_path(3)


title: securetty_types(5)

text:
# securetty_types(5)

## NAME
securetty_types - The SELinux secure tty type configuration file

## DESCRIPTION
The securetty_types file contains a list of types associated to secure tty type that are defined in the policy for use by SELinux-aware applications.

selinux_securetty_types_path(3) will return the active policy path to this file. The default securetty types file is:

/etc/selinux/{SELINUXTYPE}/contexts/securetty_types

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

selinux_check_securetty_context(3) reads this file to determine if a context is for a secure tty defined in the active policy.

SELinux-aware applications such as newrole(1) use this information to check the status of a tty.

## FILE FORMAT
Each line in the file consists of the following entry:

type One or more type entries that are defined in the policy for secure tty devices.

## EXAMPLE
\# ./contexts/securetty_types

sysadm_tty_device_t

user_tty_device_t

staff_tty_device_t

## SEE ALSO
selinux(8), selinux_securetty_types_path(3), newrole(1), selinux_check_securetty_context(3), selinux_config(5)


title: selabel_db(5)

text:
# selabel_db(5)

## NAME
selabel_db - userspace SELinux labeling interface and configuration file format for the RDBMS objects context backend

## SYNOPSIS
\#include <selinux/label.h>

int selabel_lookup(struct selabel_handle *hnd,

char **context,

const char *object_name, int object_type);

int selabel_lookup_raw(struct selabel_handle *hnd,

char **context,

const char *object_name, int object_type);

## DESCRIPTION
The DB contexts backend maps from a pair of object name and class into security contexts. It is used to find the appropriate context for database objects when relabeling a certain database. The returned context must be freed using freecon(3).

selabel_lookup(3) describes the function with its return and error codes.

The object_name should be a fully qualified name using the hierarchy of database objects. For example, the pg_class table in the postgres database and pg_catalog schema should be qualified as:

Bpostgres.pg_catalog.pg_class

The NOTES section has further information on database support for namespace hierarchies.

The object_type argument should be set to one of the following values:

SELABEL_DB_DATABASE

The object_name argument specifies the name of a database itself, such as "postgres".

SELABEL_DB_SCHEMA

The object_name argument specifies the name of a schema object, such as "postgres.public".

SELABEL_DB_TABLE

The object_name argument specifies the name of a table object, such as "postgres.public.my_table"

SELABEL_DB_COLUMN

The object_name argument specifies the name of a column object, such as "postgres.public.my_table.user_id"

SELABEL_DB_TUPLE

The object_name argument specifies the name of a table object which contains the tuples to be relabeled, such as "postgresql.public.my_table". Note that we have no way to identify individual tuple objects, except for WHERE clause on DML statements, because it has no name.

SELABEL_DB_PROCEDURE

The object_name argument specifies the name of a procedure object, such as "postgres.public.my_func". Note that we don't support lookup of individual security contexts for procedures which have the same name but different arguments.

SELABEL_DB_SEQUENCE

The object_name argument specifies the name of a sequence object, such as "postgres.public.my_seq".

SELABEL_DB_BLOB

The object_name argument specifies the name of a large object, such as "postgres.16308". Note that a large object does not have a name, so it is identified by its identifier value.

SELABEL_DB_VIEW

The object_name argument specifies the name of a view object, such as "postgres.public.my_view".

SELABEL_DB_LANGUAGE

The object_name argument specifies the name of a language object, such as "postgres.public.tcl".

SELABEL_DB_EXCEPTION

The object_name argument specifies the name of a exception object.

SELABEL_DB_DATATYPE

The object_name argument specifies the name of a type or domain object, such as postgres.public.my_type.

Any messages generated by selabel_lookup(3) are sent to stderr by default, although this can be changed by selinux_set_callback(3).

selabel_lookup_raw(3) behaves identically to selabel_lookup(3) but does not perform context translation.

The FILES section details the configuration files used to determine the database object context.

## OPTIONS
In addition to the global options described in selabel_open(3), this backend recognizes the following options:

SELABEL_OPT_PATH

A non-null value for this option specifies a path to a file that will be opened in lieu of the standard DB contexts file. It tries to open the specfile designed for SE-PostgreSQL as default, so if another RDBMS uses this interface, it needs to give an explicit specfile designed for that RDBMS (see the FILES section for details).

## FILES
The database context file used to retrieve a context depends on the SELABEL_OPT_PATH parameter passed to selabel_open(3). If NULL, then the SELABEL_OPT_PATH value will default to the active policy database contexts location (as returned by selinux_sepgsql_context_path(3)), otherwise the actual SELABEL_OPT_PATH value specified is used (this option must be used to support databases other than SE-PostgreSQL).

The default database object contexts file is:

/etc/selinux/{SELINUXTYPE}/contexts/sepgsql_context

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

The entries within the database contexts file are shown in the Object Name String Values and FILE FORMAT sections.

## Object Name String Values
The string name assigned to each object_type argument that can be present in the database contexts file are:

object_type

Text Name

SELABEL_DB_DATABASE

db_database

SELABEL_DB_SCHEMA

db_schema

SELABEL_DB_VIEW

db_view

SELABEL_DB_LANGUAGE

db_language

SELABEL_DB_TABLE

db_table

SELABEL_DB_COLUMN

db_column

SELABEL_DB_TUPLE

db_tuple

SELABEL_DB_PROCEDURE

db_procedure

SELABEL_DB_SEQUENCE

db_sequence

SELABEL_DB_BLOB

db_blob

SELABEL_DB_EXCEPTION

db_exception

SELABEL_DB_DATATYPE

db_datatype

## FILE FORMAT
Each line within the database contexts file is as follows:

object_type object_name context

Where:

object_type This is the string representation of the object type shown in the Object Name String Values section.

object_name The key used to obtain the context based on the object_type. The entry can contain '*' for wildcard matching or '?' for substitution.

Note that if the '*' is used, then be aware that the order of entries in the file is important. The '*' on its own is used to ensure a default fallback context is assigned and should be the last entry in the object_type block.

context The security context that will be applied to the object.

The following example is for SE-PostgreSQL:

\# ./contexts/sepgsql_contexts file

\# object_type object_name context

db_database my_database system_u:object_r:sepgsql_db_t:s0

db_database * system_u:object_r:sepgsql_db_t:s0

db_schema *.* system_u:object_r:sepgsql_schema_t:s0

db_tuple row_low system_u:object_r:sepgsql_table_t:s0

db_tuple row_high system_u:object_r:sepgsql_table_t:s0:c1023

db_tuple *.*.* system_u:object_r:sepgsql_table_t:s0

## NOTES
1.

A suitable database contexts file needs to be written for the target RDBMS and the SELABEL_OPT_PATH option must be used in selabel_open(3) to load it.

2.

The hierarchy of the namespace for database objects depends on the RDBMS, however the selabel* interfaces do not have any specific support for a namespace hierarchy. SE-PostgreSQL has a namespace hierarchy where a database is the top level object with the schema being the next level. Under the schema object there can be other types of objects such as tables and procedures. This hierarchy is supported as follows:

If a security context is required for "my_table" table in the "public" schema within the "postgres" database, then the selabel_lookup(3) parameters for object_type would be SELABEL_DB_TABLE and the object_name would be "postgres.public.my_table", the security context (if available), would be returned in context.

3.

If contexts are to be validated, then the global option SELABEL_OPT_VALIDATE must be set before calling selabel_open(3). If this is not set, then it is possible for an invalid context to be returned.

## SEE ALSO
selinux(8), selabel_open(3), selabel_lookup(3), selabel_stats(3), selabel_close(3), selinux_set_callback(3), selinux_sepgsql_context_path(3), freecon(3), selinux_config(5)


title: selabel_file(5)

text:
# selabel_file(5)

## NAME
selabel_file - userspace SELinux labeling interface and configuration file format for the file contexts backend

## SYNOPSIS
\#include <selinux/label.h>

int selabel_lookup(struct selabel_handle *hnd,

char **context,

const char *path, int mode);

int selabel_lookup_raw(struct selabel_handle *hnd,

char **context,

const char *path, int mode);

## DESCRIPTION
The file contexts backend maps from pathname/mode combinations into security contexts. It is used to find the appropriate context for each file when relabeling a file system. The returned context must be freed using freecon(3).

selabel_lookup(3) describes the function with its return and error codes, however the following errno is clarified further for the file contexts backend:

ENOENT

No context corresponding to the path and mode was found - This will also be returned when the file contexts series of files have a context of <<none>> against the path (see the FILE FORMAT section).

The path argument should be set to the full pathname of the file whose assigned context is being checked. The mode argument should be set to the mode bits of the file, as determined by lstat(2). mode may be zero, however full matching may not occur.

Any messages generated by selabel_lookup(3) are sent to stderr by default, although this can be changed by selinux_set_callback(3).

selabel_lookup_raw(3) behaves identically to selabel_lookup(3) but does not perform context translation.

The FILES section details the configuration files used to determine a file context.

## OPTIONS
In addition to the global options described in selabel_open(3), this backend recognizes the following options:

SELABEL_OPT_PATH

A non-null value for this option specifies a path to a file that will be opened in lieu of the standard file contexts file. This value is also used as the base name for determining the names of local customization files.

SELABEL_OPT_BASEONLY

A non-null value for this option indicates that any local customizations to the file contexts mapping should be ignored.

SELABEL_OPT_SUBSET

A non-null value for this option is interpreted as a path prefix, for example "/etc". Only file context specifications with starting with a first component that prefix matches the given prefix are loaded. This may increase lookup performance, however any attempt to look up a path not starting with the given prefix may fail. This optimization is no longer required due to the use of file_contexts.bin files and is deprecated.

## FILES
The file context files used to retrieve the default context depends on the SELABEL_OPT_PATH parameter passed to selabel_open(3). If NULL, then the SELABEL_OPT_PATH value will default to the active policy file contexts location (as returned by selinux_file_context_path(3)), otherwise the actual SELABEL_OPT_PATH value specified is used.

If SELABEL_OPT_BASEONLY is set, then the following files will be processed:

1.

The mandatory file contexts file that is either the fully qualified file name from SELABEL_OPT_PATH.value or if NULL, then the path returned by selinux_file_context_path(3).

2.

The optional local and distribution substitution files that perform path aliasing on the 'in memory' version of the file contexts file.

These files have the same name as the mandatory file contexts file with the extensions .subs and .subs_dist added.

If the SELABEL_OPT_BASEONLY is not set, then the following files will be processed:

1.

The mandatory file contexts file that is either the fully qualified file name from SELABEL_OPT_PATH.value or if NULL, then the path returned by selinux_file_context_path(3).

2.

The optional local customizations file that has the same name as the mandatory file contexts file with the extension .local added.

selinux_file_context_local_path(3) will return the default path to this file.

3.

The optional user home directory customizations file that has the same name as the mandatory file contexts file with the extension .homedirs added.

selinux_file_context_homedir_path(3) will return the default path to this file.

4.

The optional local and distribution substitution files that perform any path aliasing on the 'in memory' version of the file contexts file (and the .local and/or .homedirs if present). These files have the same name as the mandatory file contexts file with the extensions .subs and .subs_dist added.

selinux_file_context_subs_path(3) and selinux_file_context_subs_dist_path(3) will return the default paths to these files.

The default file context series of files are:

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts.local

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts.homedirs

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts.subs

/etc/selinux/{SELINUXTYPE}/contexts/files/file_contexts.subs_dist

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

Only the file_contexts file is mandatory, the remainder are optional.

The entries within the file contexts series of files are shown in the FILE FORMAT section.

## File Contexts Format
Each line within the file_contexts and the two customization files (.local and .homedirs) is as follows:

pathname [file_type] context

Where:

pathname An entry that defines the path to be labeled. May contain either a fully qualified path, or a Perl compatible regular expression (PCRE), describing fully qualified path(s). The only PCRE flag in use is PCRE2_DOTALL, which causes a wildcard '.' to match anything, including a new line. Strings representing paths are processed as bytes (as opposed to Unicode), meaning that non-ASCII characters are not matched by a single wildcard.

file_type An optional file type consisting of: -b - Block Device -c - Character Device

-d - Directory -p - Named Pipe

-l - Symbolic Link -s - Socket

-- - Ordinary file

context This entry can be either: a.

The security context that will be assigned to the file (i.e. returned as context).

b.

A value of <<none>> can be used to indicate that the matching files should not be re-labeled and causes selabel_lookup(3) to return -1 with errno set to ENOENT.

Example:

\# ./contexts/files/file_contexts

\# pathname file_type context

/.* system_u:object_r:default_t:s0

/[^/]+ -- system_u:object_r:etc_runtime_t:s0

/tmp/.* <<none>>

## Substitution File Format
Each line within the substitution files (.subs and .subs_dist) has the form:

subs_pathname pathname

Where:

pathname A path that matches an entry in one or more of the file contexts policy configuration file.

subs_pathname The path that will be aliased (considered equivalent) with pathname by the look up process.

Example:

\# ./contexts/files/file_contexts.subs

\# pathname subs_pathname

/myweb /var/www

/myspool /var/spool/mail Using the above example, when selabel_lookup(3) is passed a path of /myweb/index.html the function will substitute the /myweb component with /var/www, therefore the path used is:

/var/www/index.html

## NOTES
1.

If contexts are to be validated, then the global option SELABEL_OPT_VALIDATE must be set before calling selabel_open(3). If this is not set, then it is possible for an invalid context to be returned.

2.

If the size of file contexts series of files contain many entries, then selabel_open(3) may have a delay as it reads in the files, and if requested validates the entries.

3.

Depending on the version of SELinux it is possible that a file_contexts.template file may also be present, however this is now deprecated.

The template file has the same format as the file_contexts file and may also contain the keywords HOME_ROOT, HOME_DIR, ROLE and USER. This functionality has now been moved to the policy store and managed by semodule(8) and genhomedircon(8).

## SEE ALSO
selinux(8), selabel_open(3), selabel_lookup(3), selabel_stats(3), selabel_close(3), selinux_set_callback(3), selinux_file_context_path(3), freecon(3), selinux_config(5), lstat(2), selinux_file_context_subs_path(3), selinux_file_context_subs_dist_path(3), selinux_file_context_homedir_path(3), selinux_file_context_local_path(3), semodule(8), genhomedircon(8)


title: selabel_media(5)

text:
# selabel_media(5)

## NAME
selabel_media - userspace SELinux labeling interface and configuration file format for the media contexts backend

## SYNOPSIS
\#include <selinux/label.h>

int selabel_lookup(struct selabel_handle *hnd,

char **context,

const char *device_name, int unused);

int selabel_lookup_raw(struct selabel_handle *hnd,

char **context,

const char *device_name, int unused);

## DESCRIPTION
The media contexts backend maps from media device names such as "cdrom" or "floppy" into security contexts. It is used to find the appropriate context for establishing context mounts on these devices. The returned context must be freed using freecon(3).

selabel_lookup(3) describes the function with its return and error codes.

The integer lookup argument is currently unused and should be set to zero.

Any messages generated by selabel_lookup(3) are sent to stderr by default, although this can be changed by selinux_set_callback(3).

selabel_lookup_raw(3) behaves identically to selabel_lookup(3) but does not perform context translation.

The FILES section details the configuration files used to determine the media context.

## OPTIONS
In addition to the global options described in selabel_open(3), this backend recognizes the following options:

SELABEL_OPT_PATH

A non-null value for this option specifies a path to a file that will be opened in lieu of the standard media contexts file.

## FILES
The media context file used to retrieve a default context depends on the SELABEL_OPT_PATH parameter passed to selabel_open(3). If NULL, then the SELABEL_OPT_PATH value will default to the active policy media contexts location (as returned by selinux_media_context_path(3)), otherwise the actual SELABEL_OPT_PATH value specified is used.

The default media contexts file is:

/etc/selinux/{SELINUXTYPE}/contexts/files/media

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

## FILE FORMAT
Each line within the media file is as follows:

device_name context

Where:

device_name The media identifier (e.g. cdrom, floppy, disk and usb).

context The context to be used for labeling the device.

Example:

\# contexts/files/media

cdrom system_u:object_r:removable_device_t

floppy system_u:object_r:removable_device_t

disk system_u:object_r:fixed_disk_device_t

## NOTES
If contexts are to be validated, then the global option SELABEL_OPT_VALIDATE must be set before calling selabel_open(3). If this is not set, then it is possible for an invalid context to be returned.

## SEE ALSO
selinux(8), selabel_open(3), selabel_lookup(3), selabel_stats(3), selabel_close(3), selinux_set_callback(3), selinux_media_context_path(3), freecon(3), selinux_config(5)


title: selabel_x(5)

text:
# selabel_x(5)

## NAME
selabel_x - userspace SELinux labeling interface and configuration file format for the X Window System contexts backend. This backend is also used to determine the default context for labeling remotely connected X clients

## SYNOPSIS
\#include <selinux/label.h>

int selabel_lookup(struct selabel_handle *hnd,

char **context,

const char *object_name, int object_type);

int selabel_lookup_raw(struct selabel_handle *hnd,

char **context,

const char *object_name, int object_type);

## DESCRIPTION
The X contexts backend maps from X Window System object names into security contexts. It is used to find the appropriate context for X Window System objects whose significance and/or usage semantics are determined primarily by name. The returned context must be freed using freecon(3).

selabel_lookup(3) describes the function with its return and error codes.

This backend is also used to determine the default context for labeling remotely connected X clients.

The object_type argument should be set to one of the following values:

SELABEL_X_PROP

The object_name argument specifies the name of a window property, such as "WM_NAME".

SELABEL_X_SELN

The object_name argument specifies the name of a selection, such as "PRIMARY".

SELABEL_X_EXT

The object_name argument specifies the name of a protocol extension, such as "RENDER".

SELABEL_X_EVENT

The object_name argument specifies the name of an event type, such as "X11:ButtonPress".

SELABEL_X_CLIENT

The object_name argument is ignored, however it should be set to either * (an asterisk or 'wildcard' that will select the default entry) or a specific entry such as "remote" in the X contexts file as shown in the EXAMPLE section. The default context for labeling remote X clients is then returned.

SELABEL_X_POLYPROP

Like SELABEL_X_PROP, but checks if the property was marked as being polyinstantiated. See NOTES below.

SELABEL_X_POLYSELN

Like SELABEL_X_SELN, but checks if the selection was marked as being polyinstantiated. See NOTES below.

Any messages generated by selabel_lookup(3) are sent to stderr by default, although this can be changed by selinux_set_callback(3).

selabel_lookup_raw behaves identically to selabel_lookup but does not perform context translation.

The FILES section details the configuration files used to determine the X object context.

## OPTIONS
In addition to the global options described in selabel_open(3), this backend recognizes the following options:

SELABEL_OPT_PATH

A non-null value for this option specifies a path to a file that will be opened in lieu of the standard X contexts file (see the FILES section for details).

## FILES
The X context file used to retrieve a default context depends on the SELABEL_OPT_PATH parameter passed to selabel_open(3). If NULL, then the SELABEL_OPT_PATH value will default to the active policy X contexts location (as returned by selinux_x_context_path(3)), otherwise the actual SELABEL_OPT_PATH value specified is used.

The default X object contexts file is:

/etc/selinux/{SELINUXTYPE}/contexts/x_contexts

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

The entries within the X contexts file are shown in the Object Name String Values and FILE FORMAT sections.

## Object Name String Values
The string name assigned to each object_type argument that can be present in the X contexts file are:

object_type

Text Name

SELABEL_X_PROP

property

SELABEL_X_SELN

selection

SELABEL_X_EXT

extension

SELABEL_X_EVENT

event

SELABEL_X_CLIENT

client

SELABEL_X_POLYPROP

poly_property

SELABEL_X_POLYSELN

poly_selection

## FILE FORMAT
Each line within the X contexts file is as follows:

object_type object_name context

Where:

object_type This is the string representation of the object type shown in the Object Name String Values section. There can be multiple lines with the same object_type string that will form a block of entries (each with a different object_name entry).

object_name These are the object names of the specific X-server resource such as PRIMARY, CUT_BUFFER0 etc. They are generally defined in the X-server source code (protocol.txt and BuiltInAtoms in the dix directory of the xorg-server source package). The entry can contain '*' for wildcard matching or '?' for substitution. Note that if the '*' is used, then be aware that the order of entries in the file is important. The '*' on its own is used to ensure a default fallback context is assigned and should be the last entry in the object_type block.

context The security context that will be applied to the object.

Example 1:

```
# object_type  object_name  context
selection      PRIMARY      system_u:object_r:clipboard_xselection_t:s0
selection      *            system_u:object_r:xselection_t:s0
```

Example 2 - This example shows how a client entry can be configured to ensure an entry is always found:

```
# object_type  object_name  context
client         *            system_u:object_r:remote_t:s0
```

## NOTES
1.

Properties and selections are marked as either polyinstantiated or not. For these name types, the "POLY" option searches only the names marked as being polyinstantiated, while the other option searches only the names marked as not being polyinstantiated. Users of the interface should check both mappings, optionally taking action based on the result (e.g. polyinstantiating the object).

2.

If contexts are to be validated, then the global option SELABEL_OPT_VALIDATE must be set before calling selabel_open(3). If this is not set, then it is possible for an invalid context to be returned.

## SEE ALSO
selinux(8), selabel_open(3), selabel_lookup(3), selabel_stats(3), selabel_close(3), selinux_set_callback(3), selinux_x_context_path(3), freecon(3), selinux_config(5)


title: service_seusers(5)

text:
# service_seusers(5)

## NAME
service_seusers - The SELinux GNU/Linux user and service to SELinux user mapping configuration files

## DESCRIPTION
These are optional files that allow services to define an SELinux user when authenticating via SELinux-aware login applications such as PAM(8).

There is one file for each GNU/Linux user name that will be required to run a service with a specific SELinux user name.

The path for each configuration file is formed by the path returned by selinux_policy_root(3) with /logins/username appended (where username is a file representing the GNU/Linux user name). The default services directory is located at:

/etc/selinux/{SELINUXTYPE}/logins

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

getseuser(3) reads this file to map services to an SELinux user.

## FILE FORMAT
Each line within the username file is formatted as follows with each component separated by a colon:

service:seuser[:range]

Where:

service The service name used by the application.

seuser The SELinux user name.

range The range for MCS/MLS policies.

## EXAMPLES
Example 1 - for the 'root' user:

\# ./logins/root

ipa:user_u:s0

this_service:unconfined_u:s0

Example 2 - for GNU/Linux user 'rch':

\# ./logins/rch

ipa:unconfined_u:s0

that_service:unconfined_u:s0

## SEE ALSO
selinux(8), PAM(8), selinux_policy_root(3), getseuser(3), selinux_config(5)


seusers

title: seusers(5)

text:
# seusers(5)

## NAME
seusers - The SELinux GNU/Linux user to SELinux user mapping configuration file

## DESCRIPTION
The seusers file contains a list GNU/Linux user to SELinux user mapping for use by SELinux-aware login applications such as PAM(8).

selinux_usersconf_path(3) will return the active policy path to this file. The default SELinux users mapping file is located at:

/etc/selinux/{SELINUXTYPE}/seusers

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

getseuserbyname(3) reads this file to map a GNU/Linux user or group to an SELinux user.

## FILE FORMAT
Each line of the seusers configuration file consists of the following:

[%group_id]|[user_id]:seuser_id[:range]

Where:

group_id|user_id The GNU/Linux user id, or if preceded by the percentage (%) symbol, then a GNU/Linux group id.

An optional entry set to __default__ can be provided as a fall back if required.

seuser_id The SELinux user identity.

range The optional level or range for an MLS/MCS policy.

## EXAMPLE
\# ./seusers

system_u:system_u:s0-s15:c0.c255

root:root:s0-s15:c0.c255

fred:user_u:s0

__default__:user_u:s0

%user_group:user_u:s0

## SEE ALSO
selinux(8), PAM(8), selinux_usersconf_path(3), getseuserbyname(3), selinux_config(5)


title: user_contexts(5)

text:
# user_contexts(5)

## NAME
user_contexts - The SELinux user contexts configuration files

## DESCRIPTION
These optional user context configuration files contain entries that allow SELinux-aware login applications such as PAM(8) (running in their own process context), to determine the context that a users login session should run under.

SELinux-aware login applications generally use one or more of the following libselinux functions that read these files from the active policy path:

get_default_context(3)

get_ordered_context_list(3)

get_ordered_context_list_with_level(3)

get_default_context_with_level(3)

get_default_context_with_role(3)

get_default_context_with_rolelevel(3)

query_user_context(3)

manual_user_enter_context(3)

There can be one file for each SELinux user configured on the system. The file path is formed using the path returned by selinux_user_contexts_path(3) for the active policy, with the SELinux user name appended, for example:

/etc/selinux/{SELINUXTYPE}/contexts/users/unconfined_u

/etc/selinux/{SELINUXTYPE}/contexts/users/xguest_u

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

These files contain context information as described in the FILE FORMAT section.

## FILE FORMAT
Each line in the user context configuration file consists of the following:

login_process user_login_process

Where:

login_process This consists of a role:type[:range] entry that represents the login process context.

user_login_process This consists of a role:type[:range] entry that represents the user login process context.

## EXAMPLE
\# Example for xguest_u at /etc/selinux/targeted/contexts/users/xguest_u

system_r:crond_t:s0 xguest_r:xguest_t:s0

system_r:initrc_t:s0 xguest_r:xguest_t:s0

system_r:local_login_t:s0 xguest_r:xguest_t:s0

system_r:remote_login_t:s0 xguest_r:xguest_t:s0

system_r:sshd_t:s0 xguest_r:xguest_t:s0

system_r:xdm_t:s0 xguest_r:xguest_t:s0

xguest_r:xguest_t:s0 xguest_r:xguest_t:s0

## SEE ALSO
selinux(8), selinux_user_contexts_path(3), PAM(8), get_ordered_context_list(3), get_ordered_context_list_with_level(3), get_default_context_with_level(3), get_default_context_with_role(3), get_default_context_with_rolelevel(3), query_user_context(3), manual_user_enter_context(3), selinux_config(5)