[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] setuid/setgid in nmh

From: David Levine
Subject: [Nmh-workers] setuid/setgid in nmh
Date: Sun, 02 Feb 2014 10:58:30 -0500


There are a few setuid/setgid calls remaining in nmh.  They're
of three types.  Using setuid as an example and not showing the
setgid analogues:

1) setuid(getuid());

This drops privileges before an exec and is normally a good
thing.  Except here, the return value isn't checked.  And, we
don't have any setuid programs in nmh now, so it's unnecessary.

2) if (geteuid() == 0) setuid(pw->pw_uid);

This would be a security hole if the executable was setuid root
because the user specifies the source of the pw data.  This is
in slocal(1), where it would be significant, and it's for nearly
all of its duration.  However, slocal is not setuid, so this is
certainly not needed.

3) setuid(geteuid());

This was in post(8) for when it called the sendmail executable
directly (-mts sendmail or -mts sendmail/pipe (spost in nmh thru
1.5)).  It's not necessary with modern sendmail or replacements.

I'll remove all those.

There is one setgid (but not setuid) call that would remain.
It's in inc(1) for when:
    1) the mail spool is not world writable,
    2) dot locking is used for it, and
    3) the dotlockfile program is not setgid.
As far as I know, those conditions don't apply to any platform
that we might actively support, including:
    Linux, Cygwin, AIX:  use fcntl (by default)
    FreeBSD, OpenBSD, Mac OS X:  use flock (by default)
    Solaris:  has world-writable mail spool

Users on those platforms don't have the setgid call in their inc
thanks to our autoconf magic.  Should we remove support for it
completely?  Users who configure a non-default locking might then
have to deal with the locking of their mail spool file.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]