negative group permissions?

Anton Shterenlikht mexas at bristol.ac.uk
Fri Feb 24 14:04:20 UTC 2012


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
%

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423


More information about the freebsd-questions mailing list