Results 1 to 7 of 7

Thread: SYSERR from sendmail in console.log

  1. #1
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    I've needed to wrestle with this one at work, just spotted it again on my home machine, and figured I'd pass the word along to those of you who (a) look at the console.log (like with the Console app) or (b) like to run diskutil repairPermissions.

    Here's a line from my console.log file:

    quote:
    Jan 29 03:15:00 gallus sendmail[926]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 93: fileclass: cannot open '/etc/mail/local-host-names': Group writable directory


    Huh??

    Well now, if you run ls -ld / ("ell-ess dash-ell-dee /") in Terminal, you'll see something like:

    quote:
    drwxrwxr-t 31 root admin 1054 Jan 27 19:41 /


    What we're really interested in here is the "filemode" string: drwxrwxr-t. It gets broken into four pieces:


    d says it's a directory ("folder")
    rwx says the owner (root) has read/write/execute permission
    rwx says the group (admin) has read/write/execute permission
    r-t says that other users have read/execute permission


    Note that the 't' at the end in the 'other' permissions flags it as "sticky", which means that the kernel does its damnedest to have the file (your root directory) loaded in memory at all times for fast access.

    The key is the second triple 'rwx' granting write permission to all users in the 'admin' group. The sendmail engine as-shipped/configured with 10.2 (this is new in Jaguar) distrusts files in its configuration directory if any directory from root (/) down to the file or the named file in question (local-host-names) is writeable by a group.

    Your OSX system's root directory (/) is writeable by group admin, so sendmail distrusts its configuration files and won't process messages.

    The fix: sudo chmod g-w / (then ls -ld / again to verify your work)

    The chmod command is used to change filemode bits -- permissions -- for files. g-w tells it to turn off group-write authority, leaving all other filemode bits unaltered.

    Note that the next time you run diskutil repairPermissions it'll switch on group-write permission for / and you'll have to reset it again. I'd be unsurprised if installing OS updates switched group-write on, too.

    Wanna check the other directories and files on that path?


    ls -ld /etc
    ls -ld /private
    ls -ld /etc/mail
    ls -ld /etc/mail/local-host-names


    Why did I include /private in the list? Because what looks like the /etc directory is actually a symbolic link pointing to the real directory /private/etc, so we have to examine /private's group permissions to be exhaustive.

    Jazzbo

  2. #2
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    Quick quiz: Anyone have a guess about why my machine was trying to send an email message at the specific time logged in that error message?

    Jazzbo

  3. #3
    Join Date
    Jun 2002
    Location
    Lawrenceville, New Jersey, USA
    Posts
    220

    Default

    Hey Jazzbo, I wonder if this is why I am getting the same error in console from macjanitor. I repaired permissions and the error comes back if I chmod g-w it goes away.
    almaink

  4. #4
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    Absolutely! So what does that imply about the source of the console log record on my machine? (If you've already figured it out and don't wanna spoil the fun, almaink, just nod sagely and wait for someone else to make the connection! If a lightbulb just switched on...)

    Jazzbo

  5. #5
    Join Date
    Feb 2001
    Location
    on the landline, Mr. Smith
    Posts
    7,787

    Default

    so what happens around:

    03:15:00

    that has been discussed at length in several recent threads? *And* has a connection to the a certain day of the week and month?

  6. #6
    Join Date
    Feb 2002
    Location
    York, PA, USA
    Posts
    339

    Default

    Well, that's a good hint! Cron runs at 3:15 (unless this is 3:15 pm in which case I'm totally wrong!). But I don't get how that relates to sendmail? Doesn't cron to some type of system maintenance on sendmail at that time?

    -Anthony

  7. #7
    Join Date
    Jun 2002
    Location
    Campbell, CA, USA
    Posts
    732

    Default

    !!BONG!!

    Okay, y'all have done a great job grokking nearly in fullness the time-stamp implications.

    At 03:15 each day, the /etc/crontab file leads the crond (time-fired-job daemon) to launch the /etc/daily (10.1) or /etc/periodic/daily/* (10.2) scripts as the root user. Those scripts do daily housekeeping (cf. keep mac on so it can do repairs? True?).

    The thing is, they're set up to write various pieces of information as output along the way. cron checks any job it launches to see whether it produces output and, if it does, emails the output to the user on whose behalf the job was run, in this case root. This is the sort of output you'd see on-screen in Terminal if you invoked the scripts manually, but from cron, there's no Terminal window.

    So because these scripts get fired off for the root user at 03:15 by cron and produce output, they result in a mail message from root to root at that time. With group-write enabled on the / directory, the mailing is aborted by /usr/sbin/sendmail with a complaint in the console.log.

    Jazzbo

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •