From owner-freebsd-audit Fri Sep 21 0: 8:19 2001 Delivered-To: freebsd-audit@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 6A80837B417 for ; Fri, 21 Sep 2001 00:08:10 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8L77je32008; Fri, 21 Sep 2001 10:07:45 +0300 (EEST) (envelope-from ru) Date: Fri, 21 Sep 2001 10:07:45 +0300 From: Ruslan Ermilov To: cjclark@alum.mit.edu Cc: freebsd-audit@FreeBSD.ORG Subject: Re: Misuse of 'nobody' user for locate(1) Message-ID: <20010921100745.G27714@sunbay.com> References: <20010920205706.A3050@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010920205706.A3050@blossom.cjclark.org>; from cristjc@earthlink.net on Thu, Sep 20, 2001 at 08:57:07PM -0700 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Not looking into the implementation, the idea sounds reasonable. On Thu, Sep 20, 2001 at 08:57:07PM -0700, Crist J. Clark wrote: > The original purpose of the 'nobody' user was for "anonymous" NFS > access. This is the account to which the superuser on a remote system > is mapped. The idea is to have a user that owns no files on the > system nor is a member of a group that has group ownership of a > file. File acesss for this user is always determined by the world > permission bits. > > This user continues to be used for this purpose and others as > well. Other systems, like Samba, can use 'nobody' as the 'GUEST' user > where again we want a user who only passes world permission > bits. The FreeBSD base system has a special uses for 'nobody.' > However, one of these has an implementation flaw. > > When building the locate(1) database, the 'nobody' user is used. This > makes perfect sense. Since 'nobody' has no user or group ownership or > special access to files, we get a locate(1) database that only > contains files that everyone can see. However, there is a small bug in > the implementation, the resulting database is owned by 'nobody.' This > violates one of the primary features 'nobody' is meant to have. Let me > say it again, THE 'nobody' USER SHOULD OWN NO FILES ON THE SYSTEM. > > Now fixing this is rather straightforward. As the things stand in the > weekly scripts, the database file is created by 'root,' chowned to > 'nobody,' and then the update script is run as 'nobody.' The update > script writes the file; this is why the file must be writeable by > 'nobody.' My solution is to have the update script write its output to > stdout. In this way, 'root' can simply redirect the output of the > update script, which is being run under 'nobody,' and the file does > not need to be owned by or writeable by 'nobody.' > > To do this, I gutted the ability of the update script to write to a > specific file. It always writes to stdout. This makes sense to me. To > have the weekly script 310.locate work properly, the database location > needed to be specified in two locations, in the update script > (/usr/libexec/locatedb) or its configuration file (/etc/locate.rc) as > well as in 310.locate. I see no reason for the script to have this > ability on its own. The location only need be defined in 310.locate. > > Here are the patches. Any comments about them or the whole idea of > eliminating 'nobody' ownership of files? Thanks. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message