From owner-freebsd-questions@FreeBSD.ORG Wed Nov 12 02:15:24 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F83716A4CE for ; Wed, 12 Nov 2003 02:15:24 -0800 (PST) Received: from munk.nu (mail.munk.nu [213.152.51.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 562A143F3F for ; Wed, 12 Nov 2003 02:15:23 -0800 (PST) (envelope-from munk@munk.nu) Received: from munk by munk.nu with local (Exim 4.24; FreeBSD 4.8) id 1AJs1y-000OYk-7x for freebsd-questions@freebsd.org; Wed, 12 Nov 2003 10:15:22 +0000 Date: Wed, 12 Nov 2003 10:15:22 +0000 From: Jez Hancock To: freebsd-questions@freebsd.org Message-ID: <20031112101522.GA93834@users.munk.nu> Mail-Followup-To: freebsd-questions@freebsd.org References: <200310111243.08231.jason@dictos.com> <035501c3909c$3d1dd8d0$a4b826cb@goo> <001c01c3a082$afab7d30$0100000a@Biggie> <200311021458.49682.malcolm.kay@internode.on.net> <1067814513.825.497.camel@verdammt.falcotronic.net> <44ad7dimrc.fsf@be-well.ilk.org> <1067898777.825.714.camel@verdammt.falcotronic.net> <001701c3a864$408415e0$fa65a8c0@ocfl061> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001701c3a864$408415e0$fa65a8c0@ocfl061> User-Agent: Mutt/1.4.1i Sender: User Munk Subject: Re: owner of dir/files X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 10:15:24 -0000 First of all please don't reply to an old thread when posting a new topic - it messes the threading up and confuses things generally. On Tue, Nov 11, 2003 at 09:58:20AM -0500, M.D. DeWar wrote: > I just noticed that when I d/led a program and un-tarred it and set it up > that the directory in the apache web root has > as owner something like 501:www . I also noticed some others that were > mysql:mysql or 500:100 for the user/group. This happens when the owner:group on the source system don't exist on the destination system. Say the owner of the files was 'mark' on the original server and his uid was 501, but no user existed on your system with uid 501, then the owner would show up just as the UID, in this case 501. > I am not sure what happens if left that way. Since there is no user/group > for those does it mean the files won't run or be served ? Depends on what the permissions of the 'other' bit are. For a file that's owner:group is 501:www, permissions of 755 on the file would mean the files would be read/write/executable (7) by the user with UID 501 - in your case noone has that UID so noone has rwx perms other than root. Similarly the file would be read/executable (5) by the 'www' group and read/executable (5) by the 'other' group. So as it is the file would be served by the webserver since the 'www' user has read/execute access. However it's not a good idea to leave files unowned on the system in case you eventually do add a user with UID 501 - in which case they would end up getting rwx perms on the file. If only the webserver will be accessing the file then you can generally just do 'chown www:www ' to change the owner:group to www:www. There are security implications of leaving files rwx by the www user, especially if the file is a config file and you have other users on the server that can run cgi scripts - the file could be overwritten by a malicious script in that case. For config files it's best to set the perms to > In my web root should all directories and files be nobody:nobody ? that could work, but only if the perms for 'other' are sufficient to allow reading of the files - since the web user is in the other group and needs to be able to read the file to be able to serve it via the httpd. > what if some are root:wheel ? The same holds again, although having files owned by root in a web docroot isn't a great idea - if the file is a CGI script and a vulnerability is found in the script and a misconfigured suexec system is in place, commands could be executed with root permissions. -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/