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.






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

gay web hosting

 

Our partners: PHP: Hypertext Preprocessor Best Web Hosting Java Web Hosting Inexpensive Web Hosting  Jsp Web Hosting

Cheapest Web Hosting Jsp Hosting Cheap Hosting

Visionwebhosting.net Business web hosting division of Web Design Plus. All rights reserved