Re: [Nmh-workers] dot locking broken?

[Marcin Cieslak]

>> David Levine <address@hidden> 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