From owner-freebsd-current@FreeBSD.ORG Wed Feb 29 16:30:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D921065674 for ; Wed, 29 Feb 2012 16:30:13 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D01B8FC08 for ; Wed, 29 Feb 2012 16:30:12 +0000 (UTC) Received: by iahk25 with SMTP id k25so2546892iah.13 for ; Wed, 29 Feb 2012 08:30:12 -0800 (PST) Received-SPF: pass (google.com: domain of jhellenthal@dataix.net designates 10.50.194.163 as permitted sender) client-ip=10.50.194.163; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jhellenthal@dataix.net designates 10.50.194.163 as permitted sender) smtp.mail=jhellenthal@dataix.net; dkim=pass header.i=jhellenthal@dataix.net Received: from mr.google.com ([10.50.194.163]) by 10.50.194.163 with SMTP id hx3mr867706igc.49.1330533012490 (num_hops = 1); Wed, 29 Feb 2012 08:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=qxiM5t4Jt+d68gNx8YUE5HytzpDBE2460XWX7fQ4nAc=; b=ABu/54MdMAjoVGi5QONUAQ58nB5RUaVe1huyKFDBE2+3lfjEc7JAU+ANr+rjdCGQid xpPJJaSqejyAFzDpkhFYzpSJYEYawqRUg5cH2wfZd0+3TlxgokI4kVIfe6Okv+NuqR6d fwVS5UhiQjJSGNW186n/CIrsUvZt29O7pJ458= Received: by 10.50.194.163 with SMTP id hx3mr704150igc.49.1330533012410; Wed, 29 Feb 2012 08:30:12 -0800 (PST) Received: from DataIX.net (adsl-99-181-159-39.dsl.klmzmi.sbcglobal.net. [99.181.159.39]) by mx.google.com with ESMTPS id cv10sm5971685igc.13.2012.02.29.08.30.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 08:30:07 -0800 (PST) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1TGU45T038964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Feb 2012 11:30:04 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1TGU4pa037563; Wed, 29 Feb 2012 11:30:04 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Date: Wed, 29 Feb 2012 11:30:04 -0500 From: Jason Hellenthal To: jb , freebsd-current@freebsd.org Message-ID: <20120229163004.GA64201@DataIX.net> References: <20120228092244.GB48977@mech-cluster241.men.bris.ac.uk> <20120228162447.GB58311@mech-cluster241.men.bris.ac.uk> <20120229072458.GA95427@DataIX.net> <20120229085716.GA66484@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120229085716.GA66484@mech-cluster241.men.bris.ac.uk> X-Gm-Message-State: ALoCoQkzeMXPo+TUL3CvQo4f/tGmDJxF8E2b3VfdB8OduQmzb6umVkxbS06p1fBfeN02Wu91KSvB Cc: brooks@freebsd.org Subject: Re: negative group permissions? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:30:13 -0000 On Wed, Feb 29, 2012 at 08:57:16AM +0000, Anton Shterenlikht wrote: > On Wed, Feb 29, 2012 at 02:24:58AM -0500, Jason Hellenthal wrote: > > > > > > On Tue, Feb 28, 2012 at 04:24:47PM +0000, Anton Shterenlikht wrote: > > > On Tue, Feb 28, 2012 at 03:07:43PM +0000, jb wrote: > > > > Anton Shterenlikht bristol.ac.uk> writes: > > > > > > > > > > > > > > This was discussed in questions@ with no resolution. > > > > > Anybody here can advise further? > > > > > ... > > > > > > > > Regarding file .seq or .SEQ > > > > > > > > It is an intermediate-processing (run-time) lockfile found in various spool > > > > dirs and their sub-dirs, like > > > > /var/spool/cron/ > > > > /at, > > > > /lpd, etc. > > > > It is used to save job# by the respective programs (cron, at, etc). > > > > You can find a ref to .SEQ in file at.c in at port sources. > > > > I did not see ref to .seq in lpr or cron port sources. > > > > > > > > The periodic security check > > > > /etc/periodic/security/110.neggrpperm > > > > checks for risque condition like > > > > ! -perm +010 -and -perm +001 > > > > > > > > The file should not be executable, according to its purpose. > > > > > > > > So the lpr.c should be changed from > > > > if ((fd = open(buf, O_RDWR|O_CREAT, 0661)) < 0) { > > > > to > > > > if ((fd = open(buf, O_RDWR|O_CREAT, 0660)) < 0) { > > > > > > > > File a bug report. > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165533 > > > > The only thing that is wrong here is the misconception of negative > > permissions. This bit of code tracks all the way back to 4.3BSD and > > probably further while LPR dates back to 3BSD. Nobody programs 661 for no > > reason and changing that code will most likely have a negative impact > > and I do not see that as a real answer to this problem. > > > > Above I see your .seq file created 0641 so not only do you have a > > negative permission on the file you are also missing a bit ;). You might > > want to review some of your other permissions to see if anything is > > missing. That has been explained all over the net for the differences > > of x86 & x86_64 systems. > > To the best of my knowledge the security warning started > to appear recently. For the previous 2 years or so I haven't > seen it. Now, I didn't modify the default security scripts, > nor the lpd system. The file is created with this permissions > because the OS created it like this, not me. I've no idea > why my file is 0641 instead of 0661. > > So, given that the lpr.c hasn't changed for years, > perhaps the periodic scripts have, and what was > earlier considered fine now is considered serious enough > to issue a security warning. > > In any case, it seems either lpr.c needs to be changed, > or if 0661 is necessary, then the periodic sripts need to > be changed to ignore this file. > Maybe brooks could give some more insight on this. ------------------------------------------------------------------------ r215213 | brooks | 2010-11-12 19:40:43 -0500 (Fri, 12 Nov 2010) | 7 lines Add an (off by default) check for negative permissions (where the group on a object has less permissions that everyone). These permissions will not work reliably over NFS if you have more than 14 supplemental groups and are usually not what you mean. MFC after: 1 week -- ;s =;