Re: file permissions, guidelines, rpmlint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> >>
> >>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.
> >>
> >
> >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

Attachment: pgpcE6zsfLnHD.pgp
Description: PGP signature

--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux