Hallo Jörg-Volker, Jörg-Volker Peetz <jvpe...@web.de> wrote: |Steffen Nurpmeso wrote on 12/02/2015 12:22:
|> S-nail ships with a special, privilege-separated program that must |> be installed SETUID root; it seems Debian installs this program as |> "/usr/lib/s-nail/s-nail-privsep". Doing "$ ls -latr" on this |> should give output like |> |> -r-sr-xr-x 1 root root 21856 Sep 11 16:09 s-nail-privsep* |> |This was | | -rwxr-xr-x 1 root root 10104 Nov 27 06:08 /usr/lib/s-nail/s-nail-privsep | |on my system. I upgraded from heirloom-mailx. Yes that was wrong. But i'm the wrong person to ask how this could have happened. |May I ask where s-nail tries to write the "dotfile"? Generic answer is that the Unix dotlock file locking method creates the dotlock file in the same directory where the mailbox file is located which is to be locked; e.g. "/var/mail/spool/user" would need a dotlock file "/var/mail/spool/user.lock". |As far as I remember, mailx didn't need the sticky root bit before. Well the old Heirloom codebase didn't do that very well, as did S-nail until just the very current release. The old codebase would have required to install the entire mailx binary with SETGID to the group of the mail spool, most likely "mail", and would have tried to create a dotlock file accordingly. I suspect it was because of the original codebase that noone i know installed this binary like that – just recall you can start a shell via `!' and `shell' etc.! So i've reimplemented that completely, and privilege-separated, so that only a very small binary that is distinct from mailx itself needs to be installed SETGID. It however turned out to be insufficient for modern Unix layout, e.g., OpenBSD doesn't even have such a group and/or the spool directory simply belongs root:root and has 0755 permissions. And, furthermore, mailx allows opening of mailboxes of different "identities" via $USER (v14.9: also $LOGNAME), -u USER and "? file %USER" *if* the real user that issues those commands has sufficient rights to do so – and then the created dotlock file would be YOU:mail and not USER:mail, so that USER would not be able to delete the dotlock of his or her own mailbox by herself! Therefore i came to the conclusion that the only sane and safe way to implement modern and correct dotlocking would be to have a SETUID "superuser" privilege-separated dotlock program, which has the sole purpose of creating a dotlock file with the USER and GROUP identities of the mailbox file for which the dotlock is to be created for. And the dotlock program can hardly be misused since it (re-)verifies that the executing user has the necessary rights to be able to read or read/write the target mailbox before it raises its privileges and creates a dotlock file for that box. Also it tries very hard not to leave behind stale lock files: different to other MUAs (which all only work SETGID as far as i know) the dotlock program keeps on running (waiting) until the lock is to be released again, and shall S-nail die or otherwise terminate then the lock will still be cleaned up by the locker, which will recognize this condition. And it is faster since only one process is ever started. (In fact i'm a little bit prowd of the solution, it may be the safest and sanest that is in existence as of today. But i may be mistaken, of course.) |> i.e., SETUID root, executable for anyone, "$ chmod 4555 FILE" as |> root (via super / sudo / su as necessary) will do. | |Yes, with the sticky bit set the mailx command works here. |But is it really necessary? Great! Well. In general "yes", but since most non-server software does it wrong and anything is still all right the answer may be "no". ^_^ Ciao, --steffen
