(debian-policy.info)Permissions and owners

---

Next: File names Prev: Log files Up: Files<2>

---

Enter node , (file) or (file)node

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.  (1)

Control information files should be owned by ‘root:root’ and either mode
644 (for most files) or mode 755 (for executables such as Note:
maintainer scripts.).

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 correspond to their local security policy by changing the
permissions on a binary: they can do this by using ‘dpkg-statoverride’,
as described below.  (2) 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).

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 that it is
unique.  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.

The use of dpkg-statoverride

   ---------- Footnotes ----------

   (1) When a package is upgraded, and the owner or permissions of a
file included in the package has changed, dpkg arranges for the
ownership and permissions to be correctly set upon installation.
However, this does not extend to directories; the permissions and
ownership of directories already on the system does not change on
install or upgrade of packages.  This makes sense, since otherwise
common directories like ‘/usr’ would always be in flux.  To correctly
change permissions of a directory the package owns, explicit action is
required, usually in the ‘postinst’ script.  Care must be taken to
handle downgrades as well, in that case.

   (2) 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 behavior.