David Levine <levinedl(_at_)acm(_dot_)org> wrote:
Marcin wrote:
Once this is fixed, inc fails to lock my spool: (those messages
appear in 1 sec intervals as we "wait" to obtain the lock)
(thaks)
It works for me on Linux. Your ls -l shows that your inc is
setgid mail. Should setgid work on FreeBSD? I saw your explanation
but haven't digested it.
FreeBSD's setgid() manpage:
STANDARDS
The setuid() and setgid() system calls are compliant with the ISO/IEC
9945-1:1990 (“POSIX.1”) specification with _POSIX_SAVED_IDS not defined
with the permitted extensions from Appendix B.4.2.2. The seteuid() and
setegid() system calls are extensions based on the POSIX concept of
_POSIX_SAVED_IDS, and have been proposed for a future revision of the
standard.
Linux setgid() manpage:
(..)
Under Linux, setgid() is implemented like the POSIX version with the
_POSIX_SAVED_IDS feature. This allows a set-group-ID program that
is not set-user-ID-root to drop all of its group privileges, do some
un-privileged work, and then reengage the original effective group
ID in a secure manner.
CONFORMING TO
SVr4, POSIX.1-2001.
Using setegid() is ok according to POSIX.1-2004, it was
previously just a BSD extension.
I think that when m_mktemp() fails we should fail with adios(),
since there is no way things get magically better by waiting.
In this case, it gives up after 3 seconds, which I think is fine.
As Ken noted, there are more general considerations. One example
of where waiting could make a difference is when trying to acquire
a lock in /tmp, when it's full.
I was also wondering if we should give the user to abort waiting for
a lock with ^C.
I tried, and ^C works for me (on Linux).
That's interesting, from what I see in the inc code SIGINT is trapped
in inc.c, lines 513++ ?
//Mrcin
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers