(resent, dunno where the 1st message went)

I kind of like the idea of using a '@' before
a file path as an "attention" marker to increase
the file validation checks, and so I'm likely to
refactor the functionality out of rpm and into
popt-1.15 as part of simplifying rpm configuration/initialization.

At the same time, I will probably add a new
poptReadConfigFiles() method whose argument
will be a colon separated list of configuration
file paths to read.

Any other opinions?

73 de Jeff

Begin forwarded message:

From: Jeff Johnson <n3...@mac.com>
Date: December 18, 2008 3:15:33 PM EST
To: popt-devel@rpm5.org
Subject: Adding poptSecuritySaneFile to popt-1.15?

I'm currently catching up with popt changes, including adding a
--[no]option toggle flag and a precedence group to options, and
perhaps attaching a table to carry named bits in a single option enum.

I see this code in rpm using popt: basically paths can be prefixed with
an '@' attention marker, which will do stricter sanity checks
on files as in:

int rpmSecuritySaneFile(const char *filename)
{
   struct stat sb;
   uid_t uid;

   if (stat(filename, &sb) == -1)
       return 1;
   uid = getuid();
   if (sb.st_uid != uid)
       return 0;
   if (!S_ISREG(sb.st_mode))
       return 0;
   if (sb.st_mode & (S_IWGRP|S_IWOTH))
       return 0;
   return 1;
}

...

       /* work-off each resulting file from the path element */
       for (i = 0; i < ac; i++) {
           const char *fn = av[i];
#if defined(RPM_VENDOR_OPENPKG) /* security-sanity-check-rpmpopt-and- rpmmacros */
           if (fn[0] == '@' /* attention */) {
               fn++;
               if (!rpmSecuritySaneFile(fn)) {
rpmlog(RPMLOG_WARNING, "existing POPT configuration file \"%s\" considered INSECURE -- not loaded\n", fn);
                   continue;
               }
           }
#endif
           (void)poptReadConfigFile(optCon, fn);
           av[i] = _free(av[i]);
       }

Should I drop the '@' prefix on file path "attention!" convention into popt instead?

Its easy enough to do, although perhaps access(2) rather
than stat(2) might be slightly better owner checking.

73 de Jeff

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to