O.K. so apparently my understanding of sane file/directory permissions seems to quite divergent from rpmlint's. So I went to both the Fedora Packaging Guildelines and FHS in a attempt to resolve the discrepancy and discovered both the Guildlines and FHS offer virtually no information.
* Is there a reference which states what file/directory permissions should be and a rationale?
* Should rpmlint really be emitting warnings and errors for items not in the guidelines? (not just about file/directory but a number of other issues which frankly seems dubious). If rpmlint and the guidelines are divergent then should rpmlint be a recommended tool during package review?
Le Lun 7 décembre 2009 23:21, John Dennis a écrit :
- Should rpmlint really be emitting warnings and errors for items not in
the guidelines? (not just about file/directory but a number of other issues which frankly seems dubious). If rpmlint and the guidelines are divergent then should rpmlint be a recommended tool during package review?
rpmlint is very convenient but
1. has been known to emit stupid warnings in the past (for example, during months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora choice, and while FPC had not asked for any filtering)
2. has refused to include checks for some Fedora packaging guidelines (because they were "distro specific" (ie the maintainer disagreed with FPC; today the same checks are performed by Debian's lintian on .debs, but rpmlint still ignores them)
I don't think this can resolved unless the rpmlint maintainer agrees to pay more attention to Fedora packaging guidelines. Right now rpmlint is whatever rpmlint maintainer feels is right. It may align or not with our own packaging guidelines.
On Tue, Dec 08, 2009 at 12:13:03PM +0100, Nicolas Mailhot wrote:
Le Lun 7 décembre 2009 23:21, John Dennis a écrit :
- Should rpmlint really be emitting warnings and errors for items not in
the guidelines? (not just about file/directory but a number of other issues which frankly seems dubious). If rpmlint and the guidelines are divergent then should rpmlint be a recommended tool during package review?
rpmlint is very convenient but
- has been known to emit stupid warnings in the past (for example, during
months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora choice, and while FPC had not asked for any filtering)
- has refused to include checks for some Fedora packaging guidelines (because
they were "distro specific" (ie the maintainer disagreed with FPC; today the same checks are performed by Debian's lintian on .debs, but rpmlint still ignores them)
I don't think this can resolved unless the rpmlint maintainer agrees to pay more attention to Fedora packaging guidelines. Right now rpmlint is whatever rpmlint maintainer feels is right. It may align or not with our own packaging guidelines.
If rpmlint upstream doesn't want to implement our guidelines, then either we need a new tool, or try to make rpmlint support 'plugins', so that we can drop extra Fedora rules into the standard upstream set without needing to hack the main source.
Daniel
Daniel P. Berrange wrote:
On Tue, Dec 08, 2009 at 12:13:03PM +0100, Nicolas Mailhot wrote:
Le Lun 7 décembre 2009 23:21, John Dennis a écrit :
- Should rpmlint really be emitting warnings and errors for items not in
the guidelines? (not just about file/directory but a number of other issues which frankly seems dubious). If rpmlint and the guidelines are divergent then should rpmlint be a recommended tool during package review?
rpmlint is very convenient but
- has been known to emit stupid warnings in the past (for example, during
months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora choice, and while FPC had not asked for any filtering)
- has refused to include checks for some Fedora packaging guidelines (because
they were "distro specific" (ie the maintainer disagreed with FPC; today the same checks are performed by Debian's lintian on .debs, but rpmlint still ignores them)
I don't think this can resolved unless the rpmlint maintainer agrees to pay more attention to Fedora packaging guidelines. Right now rpmlint is whatever rpmlint maintainer feels is right. It may align or not with our own packaging guidelines.
If rpmlint upstream doesn't want to implement our guidelines, then either we need a new tool, or try to make rpmlint support 'plugins', so that we can drop extra Fedora rules into the standard upstream set without needing to hack the main source.
One can use custom rules (and fedora does use custom rules) for quite a while.
On 12/08/2009 06:13 AM, Nicolas Mailhot wrote:
Le Lun 7 décembre 2009 23:21, John Dennis a écrit :
- Should rpmlint really be emitting warnings and errors for items not in
the guidelines? (not just about file/directory but a number of other issues which frankly seems dubious). If rpmlint and the guidelines are divergent then should rpmlint be a recommended tool during package review?
rpmlint is very convenient but
- has been known to emit stupid warnings in the past (for example, during
months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora choice, and while FPC had not asked for any filtering)
- has refused to include checks for some Fedora packaging guidelines (because
they were "distro specific" (ie the maintainer disagreed with FPC; today the same checks are performed by Debian's lintian on .debs, but rpmlint still ignores them)
I don't think this can resolved unless the rpmlint maintainer agrees to pay more attention to Fedora packaging guidelines. Right now rpmlint is whatever rpmlint maintainer feels is right. It may align or not with our own packaging guidelines.
O.K. you and few others have answered one of my questions, rpmlint is divorced from our guidelines.
But I had another question, specifically about file permissions and if there were guidelines. The question is in the context of system services. I've looked at the file ownership and permissions under /etc and /var/log and there doesn't seem to be a lot of consistency.
My personal viewpoint is that for system services normal users should not be able to read configuration files and logs. Files/directories should have uid of root (0) and a gid belonging to the special daemon user associated with the service (which implicitly includes a special daemon group). Permissions should be set up to allow only root and the daemon user access to read and write files and search directories for that service. Normal users (e.g. users who are neither root nor in the daemon special group) should not be given read permission on files nor execute permission on directories. In other words the mode 755 is not correct for files owned by system services, it should be either 770 or 750 depending on the file/directory. Rpmlint is recommending 775 for everything as far as I can tell and I think is wrong. Is there a consensus on file permissions for "system" packages? Would others agree with the basic philosophy I outlined or do you take issue with it? FWIW I've never seen a recommendation written on this topic, it seems to be anecdotal, historical and inconsistent rather than prescribed.
On 12/08/2009 05:06 PM, John Dennis wrote:
On 12/08/2009 06:13 AM, Nicolas Mailhot wrote:
Le Lun 7 décembre 2009 23:21, John Dennis a écrit :
- Should rpmlint really be emitting warnings and errors for items not in
the guidelines? (not just about file/directory but a number of other issues which frankly seems dubious). If rpmlint and the guidelines are divergent then should rpmlint be a recommended tool during package review?
rpmlint is very convenient but
- has been known to emit stupid warnings in the past (for example,
during months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora choice, and while FPC had not asked for any filtering)
- has refused to include checks for some Fedora packaging guidelines
(because they were "distro specific" (ie the maintainer disagreed with FPC; today the same checks are performed by Debian's lintian on .debs, but rpmlint still ignores them)
I don't think this can resolved unless the rpmlint maintainer agrees to pay more attention to Fedora packaging guidelines. Right now rpmlint is whatever rpmlint maintainer feels is right. It may align or not with our own packaging guidelines.
O.K. you and few others have answered one of my questions, rpmlint is divorced from our guidelines.
But I had another question, specifically about file permissions and if there were guidelines. The question is in the context of system services. I've looked at the file ownership and permissions under /etc and /var/log and there doesn't seem to be a lot of consistency.
My personal viewpoint is that for system services normal users should not be able to read configuration files and logs. Files/directories should have uid of root (0) and a gid belonging to the special daemon user associated with the service (which implicitly includes a special daemon group). Permissions should be set up to allow only root and the daemon user access to read and write files and search directories for that service. Normal users (e.g. users who are neither root nor in the daemon special group) should not be given read permission on files nor execute permission on directories. In other words the mode 755 is not correct for files owned by system services, it should be either 770 or 750 depending on the file/directory. Rpmlint is recommending 775 for everything as far as I can tell and I think is wrong. Is there a consensus on file permissions for "system" packages?
The unspoken rule sofar has been:
Unless a file contains "confident"/"security relevant" information it should be set 755. If it contains such infos it should not be set 755.
This avoids user-side~, packager~ confusion and technical problems related to files which are required to be system-wide readable.
Would others agree with the basic philosophy I outlined or do you take issue with it?
No, I don't, for the reasons outlined above.
FWIW I've never seen a recommendation written on this topic, it seems to be anecdotal, historical and inconsistent rather than prescribed.
It's not that inconsistant as you seem to presume :-=)
Ralf
On Tue, 2009-12-08 at 18:26 +0100, Ralf Corsepius wrote:
The unspoken rule sofar has been:
Unless a file contains "confident"/"security relevant" information it should be set 755. If it contains such infos it should not be set 755.
This avoids user-side~, packager~ confusion and technical problems related to files which are required to be system-wide readable.
There's nothing wrong with readable configuration files unless there's something in them of a sensitive nature - no need to protect users so much from themselves that they can't see what's going on.
Jon.
On Tue, Dec 08, 2009 at 06:26:11PM +0100, Ralf Corsepius wrote:
On 12/08/2009 05:06 PM, John Dennis wrote:
On 12/08/2009 06:13 AM, Nicolas Mailhot wrote:
Le Lun 7 décembre 2009 23:21, John Dennis a écrit :
- Should rpmlint really be emitting warnings and errors for items not in
the guidelines? (not just about file/directory but a number of other issues which frankly seems dubious). If rpmlint and the guidelines are divergent then should rpmlint be a recommended tool during package review?
rpmlint is very convenient but
- has been known to emit stupid warnings in the past (for example,
during months it failed *any* spec file with UTF-8 inside, when UTF-8 was a Fedora choice, and while FPC had not asked for any filtering)
- has refused to include checks for some Fedora packaging guidelines
(because they were "distro specific" (ie the maintainer disagreed with FPC; today the same checks are performed by Debian's lintian on .debs, but rpmlint still ignores them)
I don't think this can resolved unless the rpmlint maintainer agrees to pay more attention to Fedora packaging guidelines. Right now rpmlint is whatever rpmlint maintainer feels is right. It may align or not with our own packaging guidelines.
O.K. you and few others have answered one of my questions, rpmlint is divorced from our guidelines.
Yes. rpmlint is required to be run on the packages by the packaging guidelines and generally the advice it gives is sensible and should be followed. However, there are times when it gives advice that is incorrect just as lint can sometimes be incorrect in its warnings about things happening in a C file. Rpmlint points out things that packagersand reviewers should consider before approving a package but sometimes that consideration leads to the conclusion that in this case, no change needs to be made.
But I had another question, specifically about file permissions and if there were guidelines. The question is in the context of system services. I've looked at the file ownership and permissions under /etc and /var/log and there doesn't seem to be a lot of consistency.
My personal viewpoint is that for system services normal users should not be able to read configuration files and logs. Files/directories should have uid of root (0) and a gid belonging to the special daemon user associated with the service (which implicitly includes a special daemon group). Permissions should be set up to allow only root and the daemon user access to read and write files and search directories for that service. Normal users (e.g. users who are neither root nor in the daemon special group) should not be given read permission on files nor execute permission on directories. In other words the mode 755 is not correct for files owned by system services, it should be either 770 or 750 depending on the file/directory. Rpmlint is recommending 775 for everything as far as I can tell and I think is wrong. Is there a consensus on file permissions for "system" packages?
The unspoken rule sofar has been:
Unless a file contains "confident"/"security relevant" information it should be set 755. If it contains such infos it should not be set 755.
This avoids user-side~, packager~ confusion and technical problems related to files which are required to be system-wide readable.
+1
If the files do not contain sensitive information then there's no reason to protect them with 0750 permissions.
-Toshio
packaging@lists.fedoraproject.org
-
Daniel P. Berrange -
John Dennis -
Jon Masters -
Manuel Wolfshant -
Nicolas Mailhot -
Ralf Corsepius -
Toshio Kuratomi