From owner-freebsd-current Thu Nov 16 10:59:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id AFD3437B4C5 for ; Thu, 16 Nov 2000 10:59:09 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.109]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id eAGIwk813390; Thu, 16 Nov 2000 20:58:52 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id eAGIwi034856; Thu, 16 Nov 2000 20:58:44 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A142E60.56B444F0@FreeBSD.org> Date: Thu, 16 Nov 2000 20:58:40 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: "Andresen,Jason R." Cc: Garrett Wollman , void , freebsd-current@FreeBSD.org Subject: Re: Proper permissons on /var/mail References: <20001116151809.A15312@firedrake.org> <200011161636.LAA83126@khavrinen.lcs.mit.edu> <3A1412C1.96608727@mitre.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Andresen,Jason R." wrote: > Garrett Wollman wrote: > > > > < said: > > > > > I have a similar problem -- every time I make world, perms on /var/mail > > > get set to 775. Mutt considers my mailbox read-only until I change it > > > to 1777. > > > > It is misconfigured (or perhaps just broken). 1777 mode for /var/mail > > is insecure, but was necessary in the mists of ancient past, before > > UNIX learned to do file locking. Unless your mail spool is shared > > over NFS (don't do that), locking is reliable and .lock files should > > never be used or relied upon. > > Not the FreeBSD's file locking works anyway. > Here's the results from a test of the below program: You test case is incorrect. Following quote from flock(2) explains why: [...] NOTES Locks are on files, not file descriptors. That is, file descriptors du- plicated through dup(2) or fork(2) do not result in multiple instances of a lock, but rather multiple references to a single lock. If a process holding a lock on a file forks and the child explicitly unlocks the file, the parent will lose its lock. [...] -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message