[email protected] (Jérémie Courrèges-Anglas) wrote: |Steffen Nurpmeso <[email protected]> writes: |> Jeremie Courreges-Anglas <[email protected]> wrote:
|>|This release brings an additional executable to perform dot-locking |>|against mailboxes. Since by default on OpenBSD /var/mail belongs to |>|root:wheel, mode 755 there is no way for that (setgid) executable to |>|work, so I removed it from the build (WANT_PRIVSEP=0). |> |> You and William could also use the attached patch, feel free and |Thanks for the quick fix, however we'll go with 14.8.3 without patches. Yes, that is better; i have commented on and "#if 0" the code out again on the [master] branch for now, simply doing "setuid(CONFIGURED-UID)" cannot be the answer here. At least not a satisfying one, that is to say. |(I just committed the update). The "dotlock" will be dealt with in an |upcoming update (v14.x? v15?). Many thanks for the update! And short: yes, of course, but i have to think about it first [1].. And then i'm now doing some S-roff to have a nice little summer break. Which i wish you too. Ciao! [1] So i have to do something about that. That is clear. Even with SETGID the situation is suboptimal already because of Mail(1)s / POSIX mailx(1)s possibility to open any system mailbox of a USER via %USER, and $USER / -u USER there is too. Yet we are running as A and may dotlock as B, so there is A-B-C, and then %USER is just a string that gets lost once it is expanded to MAILSPOOL/user unless we have the object-based v15 environment. So i think i will end up adding a global bypass for the next subminor in order not to loose the knowledge that we are working on %USER and thus should perform dotlocking in addition to normal file locking. But i have to think about that. --steffen
