Michael Talbot-Wilson <mtw(_at_)birdseye(_dot_)view(_dot_)net(_dot_)au> writes:
...
Thanks. The assumption seems mistaken, however (first para), and the
conduct in any event gratuitous (second para). Quote:
+ A file is marked as a candidate for mandatory locking by setting the
+ group-id bit in its file mode but removing the group-execute bit. This
+ is an otherwise meaningless combination, and was chosen by the System
+ V implementors so as not to break existing user programs.
You are *trying* to use mandatory locking on mailspools? I didn't think
of that because I would have expected you to mention such an intention
in your original post. Do you have a particular reason for doing so?
Mandatory locking looks great, but doesn't help prevent conflicts
as much as you might guess. As far as I can see, it only provides a
benefit if the file involved is accessed by multiple processes, all but
one of which use kernel locking: if they all use kernel locks, then the
mandatory nature of the locks doesn't solve any problems, while if more
than one process isn't using kernel locks than there's still nothing to
stop _them_ from colliding.
As for the "so as not to break existing user programs", that is definitely
not true of all implementations of mandatory locks. Indeed, the document
you cite says:
All the reference systems reject all calls to open() for a file
on which another process has outstanding mandatory locks. This
is in direct contravention of SVID 3, which states that only
calls to open() with the O_TRUNC flag set should be rejected. The
Linux implementation follows the SVID definition, which is the
"Right Thing", since only calls with O_TRUNC can modify the
contents of the file.
The behavior of the reference systems (but not Linux) does change the
behavior programs (consider a program that uses non-blocking fcntl()
lock calls).
+ Note that the group-id bit is usually automatically cleared by the
+ kernel when a setgid file is written to. This is a security
+ measure. The kernel has been modified to recognize the special case of
+ a mandatory lock candidate and to refrain from clearing this
+ bit. Similarly the kernel has been modified not to run mandatory lock
+ candidates with setgid privileges.
I don't understand how this paragraph implies that procmail's conduct
is gratuitous. Procmail isn't doing this to avoid unsetting a setuid
or setgid bit. As I understand it, this behavior is inherited from an
earlier SysV mail system that used either the setuid or setgid bit on
mailspools to mark them as 'autoforwarding'. This dates back some ways,
as it was implemented in procmail some time before version 3.10 in 1994,
though I don't know how much earlier.
You're of course free to remove the relevant test from procmail---a search
for 'autoforwarding' in the source will quickly show you the spot---but
given the lack of real benefits from mandatory locking I see no reason
to consider this a bug or change procmail's behavior.
Philip Guenther
Procmail Maintainer
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail