Date: Thu, 31 Oct 1996 15:56:58 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: MRC@Panda.COM (Mark Crispin) Cc: terry@lambert.org, gpalmer@FreeBSD.org, jgreco@brasil.moneng.mei.com, j@uriah.heep.sax.de, roberto@keltia.freenix.fr, current@FreeBSD.org, scrappy@ki.net Subject: Re: /var/mail (was: re: Help, permission problems...) Message-ID: <199610312256.PAA26482@phaeton.artisoft.com> In-Reply-To: <MailManager.846796721.5917.mrc@Ikkoku-Kan.Panda.COM> from "Mark Crispin" at Oct 31, 96 01:18:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Failing that, you could look at /var/mail with stat and look at st_dev
> > to see if it was NFS
>
> Alas!! Been there, done that.
>
> Using st_dev to check for NFS isn't portable. There's no portable way to
> check for NFS on BSD systems. On SVR4, you could do ustat and check f_tinode,
> but SUN broke that in Solaris 2.5.
There are section (3) rotuines for parsing the mounted file systems and
the fstab. You can compare the st_dev with the active mount points, so
it is possible (these interfaces are a BSD4.4 introduction.
> > and the permissions to see if they will let your
> > users create .lock files successfully.
>
> Of course, you do this on a file-by-file basis, since it may work in some
> directories but not others (not all mail is on /var/mail).
>
> Or, you could just try to create the .lock file and see what happens.
>
> OK, we're still on the same track.
>
> > You may not be able to know that fcntl() *will* work, but you can know
> > .lock files *won't* work.
>
> So, what do we do now? We've determined that .lock files won't work. We no
> longer have any guidance from run time tests. We have to choose a policy from
> here.
>
> What are our choices?
> 1) Error: "Lock failed, mailbox open aborted"
> 2) Warning: "Lock failed, proceeding as if locked"
> 3) Ignore the condition entirely.
How about:
4) Warning: "Lock failed, using fcntl locking"
or
5) Silently switch to fcntl() locking, since the system
policy set by the mail directory permissions can't
be changed by Joe Average User
?
> Policy (3) is extremely dangerous unless you know that .lock files are never
> needed. This is probably right for FreeBSD users who never use NFS, and know
> they will never do so.
>
> I distribute the software with policy (2), and a build-time conditional to set
> policy (3).
Actually, policy 2 or 3 is correct for NFS as well, assuming the changes
pending in the core team are ever integrated, and assuming it fails over
to fcntl() (in which case 2 is 4 and 3 is 5).
> In other words, it doesn't. The only thing it can do is be prepared. Good
> Boy Scout software it is, yessiree. Apply every possible lock I can, that's
> the trick.
Brave yes, thrifty, no. 8^).
> > Again, I would prefer runtime configuration. If nothing else, because
> > I use AMD to relocate my mail files to user accounts, and some are local
> > and some are NFS mounted.
>
> This is EXACTLY what I'm doing for you, sir!!
>
> Now, do you have some magic run time test that could lead me to discriminate
> between the two cases:
> 1) system call locking was the right thing, don't worry.
> 2) you really needed the .lock file, and the fool who set up the
> system did so in a way that you don't have privileges to lock the
> mail file.
> If you did, I'd be happier than a pig in mud.
Stat the directory where the .lock file will be created. If you can
do it, do it and fcntl() (fcntl() is important for interoperability
for MUA's and MDA'a and MTA's that already use fcntl()) both.
If you can't do it, assume the permission are set intentionally to
dictate locking policy (ie: it's not an error condition you need to
flag for the user; if anyone should be flagged, it should *only* be
the admin). Then silently fall back to fcntl().
> About 6 years ago, a VAX BSD guru assured me that "turn off the annoying
> message; if .lock file locking fails, system call locking is the right thing,
> don't worry." I made the mistake of believing him.
>
> I subsequently have YEARS of unhappy experience with systems that use setgid
> access to the mail spool. This is a particularly nasty problem, since the
> poor guys don't know that they have a problem for months until bad luck
> strikes and mail delivery happens while their mailbox is being rewritten.
> And, for a while, they put it down as a random glitch or user goof, until a
> long-term continuous patten comes up. And when they finally ask for help,
> they are VERY upset, and even more upset to learn that the condition was
> detected but they were never told about it.
If you have a SGID mailspool, clearly the system expects .lock locking
(I think a stat of the target mailspool, even if all mailspools aren't
in the same place, is enough to tell you on a per mailspool basis).
The mistaken VAX BSD "guru" not withstanding. 8-).
The fcntl() can never hurt. Taking the stat of the target mailspool
as a runtime configuration option seems to be the right thing to do.
For users who incorrectly configure their own folder directories: there
are rules, dictated by system policy, for setting these things up. If
you fail to follow the rules, the results are "undefined".
For the vast majority ofusers, the admin sets up their mailspool for
them, and they have no say in the matter.
> It is going to take a lot more than flaming to get me to trust the word of BSD
> folks again. You're going to have to show me what I can do to make things any
> better for you without reintroducing this problem in the remaining 99% of the
> market.
You should take VAX BSD folks with caution. Us BSD 4.4 folks are much
more trustworthy. 8-) 8-).
> > By publicising the fact that fcntl and flock locking are available on
> > all POSIX conformant and POSIX compliant systems, and that POSIX
> > strictly mandates how an FS must act, and NFS is an FS?
>
> Too many NFS clusters have had cluster-wide shutdowns from lockd/statd.
They should be fixed.
> I am unaware of any POSIX requirement that "mail spool locking must be done
> using fcntl() and must not be done by using .lock files". If there is such a
> requirement, it's being widely ignored out there. Out of 3 dozen UNIX
> variants that I support, only two are believed to have mail delivery programs
> that use fcntl() or flock().
I didn't say that; I said that fcntl() must work. If it doesn't, it's
a non-{conformant|compliant} system and should be ratted out to the
press so they have to fix it.
> > Actually the question is where there will be a BSD4.4-Lite specific #ifdef
> > for the default FreeBSD configuration to avoid the warning so that we
> > don't have to hack around the warning using "port" code.
>
> Sigh. How many times did I tell you that the conditional is already there?
> For the benefit of the lazy, it's IGNORE_LOCK_EACCES_ERRORS. So, assuming you
> still use the neb port, it's
> make neb -DIGNORE_LOCK_EACCES_ERRORS
>
> This is not going to be the default, because of the reasons with NFS outlined
> above.
But .lock will not work. Ever. BSD mail spools are not 1777. They
will not be changed to 1777 because of the denial-of-service vulnerability
doing that will introduce.
If it is within the BSD camp's power (or at least this member of the camp),
the denial-of-service vulnerability will be CERT advisoried, and *nobody's*
mail spool will be 1777 in the future. The .lock files will begin to
fail elsewhere as other systems are corrected to comply with the CERT
advisory.
> Recently:
>
> The guys at IBM swore on a stack of Bibles that it would work in AIX, and
> backed up their word with an offer of free RS/6000s if it didn't work. Thanks
> for the free machines, guys.
I'd be interested in this "free machine" offer. 8-).
> They guys at SUN swore up and down that they got it working on Solaris 2.5.
> Well, the field results are in. It doesn't work. Now they're saying 2.6, for
> sure. At least one of my spys inside SUN is wagering with me that it won't.
It works in 4.1.3_U2 and 4.1.4, AFAIK. Solaris is a different kettle of
fish. I'd expect it to fail there because of server caching (which you
can turn off -- procedure is documented on Sunsite).
You will take a big hit on write performance if you do that, but you
have to do it anyway to get the write gurantees from the NFS protocol
definition.
> Now, you guys may be smarter than the guys at IBM and SUN, and will come up
> with fcntl()/lockd/statd that works for everyone. That would be great news,
> and you would save the world.
Heh. 8-).
> By the way, in terms of saving the world, here's a few more items:
>
> I hope that you'll fix the bug in fcntl() that if you have a lock on a file,
> and then lock the same file on a different file designator in the same
> process, the first lock is blown away. This apparently happens even if the
> locks are owned by different threads in the same process; locks are apparently
> recorded in a per-process inode table.
This comes from the lock list being hung of the inode instead of the
vnode (in FreeBSD anyway). Patches have been submitted which fix this.
Is this a currently existing BSD problem? It will be fixed.
> Oh, and there's also the flock() bug that if you promote a lock from shared to
> exclusive, or demote from exclusive to shared, the lock is actually unlocked.
> I didn't check to see if fcntl() has the same bug.
I expect it would, if this is a BSD bug. The code is shared.
The lock promotion, I understand... it's possible to do it right, but
almost no one does. There is a race while the vnode is unlocked that
is there because of the way VOP_ADVLOCK is (incorrectly) layered as a
call-down interface. Patches have been submitted which fix this.
Is this a currently existing BSD problem? It will be fixed.
> Consider adding locks by a named resource on a file, so it is possible to have
> multiple locks on the same file but with different purposes. File data
> sections don't cut it; I want names so I can define my own resources. In
> particular, I want a resource which indicates "file open by mailer", and which
> must be exclusive in order to remove messages; and another one which indicates
> "currently parsing mailbox data", and which must be exclusive in order to
> append new data. Neither flock() nor fcntl() give this level of support, yet
> DEC's and IBM's old proprietary operating systems did.
Yeah. This is an implied state issue.
The only way to deal with this is to provide a hard connection across
the implied state.
Actually, I'd suggest solvng the problem by imposing a promption and
demotion order protocol, and an override. The override would, unfortunately,
require you to extend the fcntl interface to handle "append" locks which
don't allow write to intermediate data while the end is locked. This
would only get hairy for mmap'ed files...
For the append, you could write-lock the area after the end of the
file to infinity even with a read (shared) lock on the earlier
data in the file.
To get better than that, you would need a record oriented FS so that
each mail message was treated as a record so you could delete internal
to the file without losing the data appended to the end. In other
words, you'd lock a record range, and idempotently manipulate the
records without affecting the record offsets created by another user.
Probably the right way to do this would be to index the mailbox in
a seperate file and implie the states with write order for a two
stage indexed commit (standard database technique, where a new data
record is written before the index is updated).
This is an application library issue more than it's a single file
locking issue. That means the best place to put it might be c-client.
8-(.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610312256.PAA26482>