Chapter 10. Files

85

This rotates all files under

/var/log/foo

, saves 12 compressed generations, and forces the

daemon to reload its configuration information after the log rotation.

Log files should be removed when the package is purged (but not when it is only removed).

This should be done by the

postrm

script when it is called with the argument

purge

(see

`Details of removal and/or configuration purging' on page

44

).

10.9 Permissions and owners

The rules in this section are guidelines for general use. If necessary you may deviate from the

details below. However, if you do so you must make sure that what is done is secure and you

should try to be as consistent as possible with the rest of the system. You should probably also

discuss it on

debian devel

first.

Files should be owned by

root.root

, and made writable only by the owner and universally

readable (and executable, if appropriate), that is mode 644 or 755.

Directories should be mode 755 or (for group writability) mode 2775. The ownership of the

directory should be consistent with its mode: if a directory is mode 2775, it should be owned

by the group that needs write access to it.

Setuid and setgid executables should be mode 4755 or 2755 respectively, and owned by the

appropriate user or group. They should not be made unreadable (modes like 4711 or 2711

or even 4111); doing so achieves no extra security, because anyone can find the binary in the

freely available Debian package; it is merely inconvenient. For the same reason you should not

restrict read or execute permissions on non set id executables.

Some setuid programs need to be restricted to particular sets of users, using file permissions.

In this case they should be owned by the uid to which they are set id, and by the group which

should be allowed to execute them. They should have mode 4754; again there is no point in

making them unreadable to those users who must not be allowed to execute them.

It is possible to arrange that the system administrator can reconfigure the package to corre 

spond to their local security policy by changing the permissions on a binary: they can do this

by using

dpkg statoverride

, as described below.

8

Another method you should consider

is to create a group for people allowed to use the program(s) and make any setuid executables

executable only by that group.

If you need to create a new user or group for your package there are two possibilities. Firstly,

you may need to make some files in the binary package be owned by this user or group, or you

may need to compile the user or group id (rather than just the name) into the binary (though

this latter should be avoided if possible, as in this case you need a statically allocated id).

8

Ordinary files installed by

dpkg

(as opposed to

conffile

s and other similar objects) normally have

their permissions reset to the distributed permissions when the package is reinstalled. However, the use of

dpkg statoverride

overrides this default behaviour. If you use this method, you should remember to describe

dpkg statoverride

in the package documentation; being a relatively new addition to Debian, it is probably not

yet well known.