negative group permissions?
Trond Endrestøl
Trond.Endrestol at fagskolen.gjovik.no
Sat Feb 25 07:38:25 UTC 2012
On Fri, 24 Feb 2012 14:48-0000, Anton Shterenlikht wrote:
> On Fri, Feb 24, 2012 at 03:25:52PM +0100, Trond Endrest?l wrote:
> > On Fri, 24 Feb 2012 14:04-0000, Anton Shterenlikht wrote:
> >
> > > On Fri, Feb 24, 2012 at 02:41:44PM +0100, Trond Endrest?l wrote:
> > > > On Fri, 24 Feb 2012 12:54-0000, Anton Shterenlikht wrote:
> > > >
> > > > > On Fri, Feb 24, 2012 at 09:34:02AM +0000, Matthew Seaman wrote:
> > > > > > On 24/02/2012 09:08, Anton Shterenlikht wrote:
> > > > > > > Recently I started seeing this line
> > > > > > > in daily security output:
> > > > > > >
> > > > > > > Checking negative group permissions:
> > > > > > > 70834 -rw-r----x 1 root daemon 4 Feb 21 12:54:02 2012 /var/spool/output/lpd/.seq
> > > > > > >
> > > > > > > I've a parallel printer attached to
> > > > > > > a 9.9-CURRENT #2 r230787M box.
> > > > > > >
> > > > > > > What does it mean?
> > > > > >
> > > > > > This means that non-root users in group daemon have only read
> > > > > > permissions on that file. Users that aren't root and that aren't in
> > > > > > group daemon have execute permission only.
> > > > > >
> > > > > > It does look a bit odd, and I believe that file would just contain a job
> > > > > > number (IIRC -- haven't dealt much with lpd or lprng much recently)
> > > > > > so executing it doesn't really achieve anything.
> > > > > >
> > > > > > This is the standard idiom to allow access for 'everyone, except members
> > > > > > of a particular group.'
> > > > >
> > > > > yes, I get this.
> > > > >
> > > > >
> > > > > > One way you can get weird permissions is if you happen to use decimal
> > > > > > for permissions bitmaps rather than octal. A umask of '77' is not the
> > > > > > same thing at all as a umask of '077'. (It's effectively 0115, which
> > > > > > doesn't make much sense to me.) Most shells nowadays will assume you
> > > > > > mean octal whether you include the leading zero or not: the same is not
> > > > > > true if you use umask(2) to set the mask programatically. Ditto for
> > > > > > other places you can set permissions like open(2) with O_CREAT or mkdir(2).
> > > > >
> > > > > # umask
> > > > > 0022
> > > > > # pwd
> > > > > /var/spool/output/lpd
> > > > > # ls -al
> > > > > total 8
> > > > > drwxr-xr-x 2 root daemon 512 Feb 24 12:43 .
> > > > > drwxr-xr-x 3 root daemon 512 Mar 9 2010 ..
> > > > > -rw-rw-r-- 1 root daemon 41 Feb 21 12:54 lock
> > > > > -rw-rw-r-- 1 root daemon 25 Feb 21 12:54 status
> > > > > #
> > > > >
> > > > > Then I print something:
> > > > >
> > > > > % pwd | lpr
> > > > >
> > > > > Then this .seq file appears with weird permissions:
> > > > >
> > > > > # ls -al
> > > > > total 10
> > > > > drwxr-xr-x 2 root daemon 512 Feb 24 12:46 .
> > > > > drwxr-xr-x 3 root daemon 512 Mar 9 2010 ..
> > > > > -rw-r----x 1 root daemon 4 Feb 24 12:45 .seq
> > > > > -rw-rw-r-- 1 root daemon 41 Feb 24 12:45 lock
> > > > > -rw-rw-r-- 1 root daemon 25 Feb 24 12:45 status
> > > > > #
> > > > >
> > > > > # cat .seq
> > > > > 001
> > > > > #
> > > > >
> > > > > So presumably lpd(8) created this file, but I'm still
> > > > > unsure why permissions are so strange. But interests
> > > > > me more, is why I didn't see it until about 1-2 months
> > > > > ago? Has something chaged in -current, e.g. in open(2)
> > > > > like you suggest? Or has I messed up with my setup?
> > > > > Or maybe it was always like this, but the security
> > > > > check didn't pick it up?
> > > > >
> > > > > >
> > > > > > > Should I be worried?
> > > > > >
> > > > > > No more than a normal level of paranoia is indicated here.
> > > >
> > > > Looking at usr.sbin/lpr/lpr/lpr.c at around line 847 (RELENG_9):
> > > >
> > > > (void) snprintf(buf, sizeof(buf), "%s/.seq", pp->spool_dir);
> > > > seteuid(euid);
> > > > if ((fd = open(buf, O_RDWR|O_CREAT, 0661)) < 0) {
> > > > printf("%s: cannot create %s\n", progname, buf);
> > > > exit(1);
> > > > }
> > > > if (flock(fd, LOCK_EX)) {
> > > > printf("%s: cannot lock %s\n", progname, buf);
> > > > exit(1);
> > > > }
> > > >
> > > > It remains a mystery why these files are created with mode 0661. Mode
> > >
> > > Isn't .seq above has mode 641?
> > >
> > > % chmod 641 z
> > > % ls -al z
> > > -rw-r----x 1 mexas wheel 0 Feb 24 13:59 z
> > > %
> >
> > It sure is, in all cases quoted above.
> >
> > All handling of the .seq files seems to be contained within the
> > mktemps() function of usr.sbin/lpr/lpr/lpr.c.
> >
> > The call to open(2) with the mode set to 0661 has been there since CVS
> > revision 1.1 of usr.sbin/lpr/lpr/lpr.c, see
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/lpr/lpr/lpr.c?annotate=1.45.2.1.2.1
> >
> > No calls to chmod(2) of the .seq files anywhere else, as far as I can
> > tell.
> >
> > I usually keep tight permissions on the spool directories, mode 0770.
>
> It seems I need 755, otherwise dialer and smmsp
> will not have access:
>
> # ls -al /var/spool/
> total 28
> drwxr-xr-x 8 root wheel 512 Nov 21 2009 .
> drwxr-xr-x 25 root wheel 512 Jan 31 02:03 ..
> drwxrwx--- 2 smmsp smmsp 512 Feb 24 03:39 clientmqueue
> drwxrwxr-x 2 uucp dialer 512 Jan 31 02:04 lock
> drwxr-xr-x 2 root daemon 512 Nov 21 2009 lpd
> drwxr-xr-x 2 root daemon 14336 Feb 24 03:40 mqueue
> drwx------ 2 root daemon 512 Nov 21 2009 opielocks
> drwxr-xr-x 3 root daemon 512 Mar 9 2010 output
> #
I meant the printer spool directories, sorry for not being clearer.
E.g. /var/spool/output/lpd, as in your case, or in my case,
/var/spool/lpd/*.
trond at enterprise:~>ll /var/spool/lpd
total 153
drwxr-xr-x 18 root daemon - 18B Jan 10 14:15 ./
drwxr-xr-x 11 root wheel - 11B Jan 10 14:15 ../
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp1160-223/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp1200-235/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp1320-241/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp1320-a/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp1320-b/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp1320nw/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp2015-154/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp2025-216a/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp2420-104/
drwxrwx--- 2 root daemon - 5B Feb 20 10:01 hp2430-226/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp3005-105/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp3505-223/
drwxrwx--- 2 root daemon - 5B Mar 22 2010 hp3505-225/
drwxrwx--- 2 root daemon - 5B Jan 8 19:38 hp4000-165/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp4v-243/
drwxrwx--- 2 root daemon - 2B Oct 1 2009 hp5550-221/
However only these .seq files exist on the particular system shown
above:
Checking negative group permissions:
94 -rw-r----x 1 root daemon 4 Feb 20 10:01:50 2012 /var/spool/lpd/hp2430-226/.seq
98 -rw-r----x 1 root daemon 4 Mar 22 13:39:44 2010 /var/spool/lpd/hp3505-225/.seq
103 -rw-r----x 1 root daemon 4 Jan 8 19:38:02 2012 /var/spool/lpd/hp4000-165/.seq
> > It's still a mystery. Thus it's time to bring in people with more
> > knowledge on lpr and friends.
>
> sure
I wouldn't worry about these strange permissions, but I think it's
well past the time to clean up lpr.c. Should we submit a PR?
--
+-------------------------------+------------------------------------+
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. dir. 61 14 54 39, | Office.....: +47 61 14 54 39, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+-------------------------------+------------------------------------+
More information about the freebsd-questions
mailing list