From owner-freebsd-questions@FreeBSD.ORG Fri Feb 24 14:49:06 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DEA106566B for ; Fri, 24 Feb 2012 14:49:06 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 838578FC0A for ; Fri, 24 Feb 2012 14:49:06 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1S0wS1-0002QT-De; Fri, 24 Feb 2012 14:48:59 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1S0wRe-0005mt-Tt; Fri, 24 Feb 2012 14:48:26 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q1OEmQW1004210; Fri, 24 Feb 2012 14:48:26 GMT (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q1OEmQmk004187; Fri, 24 Feb 2012 14:48:26 GMT (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Fri, 24 Feb 2012 14:48:26 +0000 From: Anton Shterenlikht To: Trond Endrest?l Message-ID: <20120224144826.GA72595@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Trond Endrest?l , Anton Shterenlikht , FreeBSD questions References: <20120224090848.GA28104@mech-cluster241.men.bris.ac.uk> <4F47598A.9080400@infracaninophile.co.uk> <20120224125430.GB8026@mech-cluster241.men.bris.ac.uk> <20120224140408.GA8384@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Anton Shterenlikht , FreeBSD questions Subject: Re: negative group permissions? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:49:06 -0000 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 # > > It's still a mystery. Thus it's time to bring in people with more > knowledge on lpr and friends. sure -- 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