Date: Thu, 16 Nov 2000 20:58:40 +0200 From: Maxim Sobolev <sobomax@FreeBSD.org> To: "Andresen,Jason R." <jandrese@mitre.org> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, void <float@firedrake.org>, freebsd-current@FreeBSD.org Subject: Re: Proper permissons on /var/mail Message-ID: <3A142E60.56B444F0@FreeBSD.org> References: <Pine.BSF.4.21.0011160650180.41866-100000@arnold.neland.dk> <20001116151809.A15312@firedrake.org> <200011161636.LAA83126@khavrinen.lcs.mit.edu> <3A1412C1.96608727@mitre.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Andresen,Jason R." wrote:
> Garrett Wollman wrote:
> >
> > <<On Thu, 16 Nov 2000 15:18:09 +0000, void <float@firedrake.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A142E60.56B444F0>