This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 12438 - Permissions funnies
Permissions funnies
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: sendmail (Show other bugs)
7.1
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Florian La Roche
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-18 15:14 EDT by Matthew Kirkwood
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-06-18 15:50:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matthew Kirkwood 2000-06-18 15:14:29 EDT
A few of perms oddities:

 * /usr/sbin/sendmail is setgid-root as well as setuid.
   Is there a reason for this?
 * Could we o-rx /var/spool/mqueue?
 * Can we restrict the use of /usr/bin/mailq to root?  I
   fail to understand why people should know who I'm
   sending email to.
Comment 1 Bill Nottingham 2000-06-18 15:33:46 EDT
Setting the permissions on mailq won't help if the user can still run
'sendmail -bp'; to change that requires patching sendmail.
Comment 2 Matthew Kirkwood 2000-06-18 15:50:01 EDT
Probably true.  mailq is just a symlink to sendmail anyway.

However, somewhere along the way (none of the Red Hat boxes I have access to run
sendmail :-) newaliases, which is also a symlink, got restricted, so it must be
doable.
Comment 3 Florian La Roche 2000-06-18 16:55:35 EDT
use restrictrunq and restrictmailq to change sendmail

I think it is good that any user can check the state of the sendmail
configuration, so I don't want to change perms.

Note You need to log in before you can comment on or make changes to this bug.