OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Jim Bernard (jbernardmines.edu)
Date: Wed Jul 25 2001 - 08:39:15 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Tue, Jul 24, 2001 at 11:09:55PM -0400, gabriel rosenkoetter wrote:
    > Uh... not that one inode is particularly likely to cause problems,
    > and I understand why this file *is* in the default mtree (despite
    > the fact that pkgsrc is not part of the default install), but the
    > "right" way to make this complaint go away is not to just create a
    > file, but rather to remove the mk.conf entry in /etc/mtree/special.

      Keep in mind that /etc/mk.conf is not just a pkgsrc-related file.
    Its existence predates the existence of pkgsrc---it is included
    via bsd.own.mk. It is common to use it to tweak system builds, not
    just package builds, and if it were left in a world-writable state
    (e.g.), it would pose a potential security risk about which it would
    be useful to be notified.

      To decide what is best for you, ask yourself a few questions:

        * Am I so certain I'll never want to create mk.conf that I'm
          better off deleting the mtree entry?

        * Will I be bothered by having to delete it anew each time I
          update the /etc/mtree files?

        * If I ever do create mk.conf, will I remember to put back the
          mtree entry?

        * Is it better to create a dummy mk.conf, both to serve as a
          reminder that I might want to put some useful stuff in it
          someday, and to keep the security script quiet?

    > It'd be a good idea to tune that file for your system in general,
    > having it monitor other files changes to which you'd like to know
    > about.

      To simplify tracking of the distributed mtree files, which change
    fairly frequently in the distribution, it might be more convenient in
    the long run to set up a separate invocation of mtree with its own
    database of files of local interest. Of course, this means no
    deletions as well.

    --Jim