Date: Fri, 21 Sep 2001 10:07:45 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> 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> In-Reply-To: <20010920205706.A3050@blossom.cjclark.org>; from cristjc@earthlink.net on Thu, Sep 20, 2001 at 08:57:07PM -0700 References: <20010920205706.A3050@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010921100745.G27714>