Chapter 10. Files

86

If you need a statically allocated id, you must ask for a user or group id from the

base passwd

maintainer, and must not release the package until you have been allocated one. Once you

have been allocated one you must either make the package depend on a version of the

base passwd

package with the id present in

/etc/passwd

or

/etc/group

, or arrange

for your package to create the user or group itself with the correct id (using

adduser

) in its

preinst

or

postinst

. (Doing it in the

postinst

is to be preferred if it is possible, otherwise

a pre dependency will be needed on the

adduser

package.)

On the other hand, the program might be able to determine the uid or gid from the user or

group name at runtime, so that a dynamically allocated id can be used. In this case you should

choose an appropriate user or group name, discussing this on

debian devel

and checking

with the

base passwd

maintainer that it is unique and that they do not wish you to use a

statically allocated id instead. When this has been checked you must arrange for your package

to create the user or group if necessary using

adduser

in the

preinst

or

postinst

script

(again, the latter is to be preferred if it is possible).

Note that changing the numeric value of an id associated with a name is very difficult, and

involves searching the file system for all appropriate files. You need to think carefully whether

a static or dynamic id is required, since changing your mind later will cause problems.

10.9.1 The use of

dpkg statoverride

This section is not intended as policy, but as a description of the use of

dpkg statoverride

.

dpkg statoverride

is a replacement for the deprecated

suidmanager

package. Pack 

ages which previously used

suidmanager

should have a

Conflicts:

suidmanager ( 

0.50)

entry (or even

(  0.52)

), and calls to

suidregister

and

suidunregister

should

now be simply removed from the maintainer scripts.

If a system administrator wishes to have a file (or directory or other such thing) installed with

owner and permissions different from those in the distributed Debian package, they can use

the

dpkg statoverride

program to instruct

dpkg

to use the different settings every time

the file is installed. Thus the package maintainer should distribute the files with their normal

permissions, and leave it for the system administrator to make any desired changes. For ex 

ample, a daemon which is normally required to be setuid root, but in certain situations could

be used without being setuid, should be installed setuid in the

.deb

. Then the local system

administrator can change this if they wish. If there are two standard ways of doing it, the pack 

age maintainer can use

debconf

to find out the preference, and call

dpkg statoverride

in

the maintainer script if necessary to accommodate the system administrator's choice.

Given the above,

dpkg statoverride

is essentially a tool for system administrators and

would not normally be needed in the maintainer scripts. There is one type of situation, though,

where calls to

dpkg statoverride

would be needed in the maintainer scripts, and that

involves packages which use dynamically allocated user or group ids. In such a situation,

something like the following idiom can be very helpful in the package's

postinst

, where

sysuser

is a dynamically allocated id:

for i in /usr/bin/foo /usr/sbin/bar