From owner-freebsd-bugs@FreeBSD.ORG Sat Apr 10 07:29:34 2010 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB192106566B for ; Sat, 10 Apr 2010 07:29:34 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6534F8FC15 for ; Sat, 10 Apr 2010 07:29:33 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 23C28439E38; Sat, 10 Apr 2010 02:30:00 -0500 (CDT) Message-ID: <4BC036E3.3070105@fuujingroup.com> Date: Sat, 10 Apr 2010 02:29:23 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Norbert Zeh , freebsd-bugs@freebsd.org References: <4BC00CC7.4080907@fuujingroup.com> <20100410065609.GL22422@cs.dal.ca> In-Reply-To: <20100410065609.GL22422@cs.dal.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: jail users can delete files they shouldn't X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 07:29:34 -0000 Norbert Zeh wrote: > Erich Jenkins, Fuujin Group Ltd [2010.04.09 2329 -0600]: >> I've gone through the archives for the Jail list, and I'm not finding >> anything specific to the issue we're experiencing. My apologies if this >> is a known issue or if I've done something daft, but there appears to be >> a file permission issue with jails. >> >> We have a large deployment of jailed systems, and an issue was brought >> to my attention today that I hope very much is the result of a >> misconfiguration or other mistake. >> >> Background: >> >> Environment is FreeBSD 7.0-REL and 8.0-REL >> Platforms include i386 (x86 Xeon), amd64 (Opteron) and sparc64 (Netra X1's) >> Jail environment is a Complete jail, not an application jail >> >> Situation: >> >> A user managed to kill an apache process today, resulting in their >> virtual web server (in a jail) going down. The user does not have root >> privileges on this box, and is not a member of wheel. Upon inspection, I >> found that the user had deleted a config file that was owned by root >> (chmod 700). It appears they were not able to read the file, but they >> were able to delete it which I confirmed with the user. >> >> Test: >> >> To verify what appeared to be happening, I created a file in the users >> home directory (typed some garbage into a text file) owned by root (700) >> and in the wheel group. I then logged into the users account via ssh as >> that user. I attempted to su to root, which I could not (as expected). I >> tried to read the file and could not (as expected). Then I tried to >> delete the file. Bingo. File was gone. > > It's not the file permissions that control whether you can delete it but > the user's permission on the directory containing the file. If the user > has write access to the directory, they can delete whatever is contained > in that directory. Since you talk about the user's home directory, I > assume they have write access. > > N. > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" I understand that, but this is not the situation. In the users home directory there is a folder which they do NOT have write access to, but they do have read access. If I cd to that directory, I can of course see the files in it, and file permissions work as expected for opening and editing. However, the directory is owned by root, and the user does not have write access to it. Therefore, it would seem I should not be able to delete the files contained in that directory. Am I missing something or perhaps slightly mad? I apologize for not making the file structure more clear when I sent the initial post out. After re-reading it, I certainly see how you interpreted my inability to communicate concisely! :) Any thoughts as to what might be causing this? FYI, when I duplicate this situation outside of a jail environment, it works as expected. The user can't delete files they don't own from directories they don't have write access to. Drop it in a jail, and we have a problem. Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder