trn@aplcomm.jhuapl.edu (Tony Nardo) (11/18/88)
Since posting my article about changing the ownership of 'in.fingerd' to a user with a non-negative user number, I've received about a dozen messages asking something along the lines > You mentioned that finger shouldn't run under a negative user > number. Could you explain why, please? As it turns out, SunOS 3.* seems perfectly happy to run 'in.fingerd' with 'nobody' as its user ID. Under SunOS 4.0, however, 'cron' sends a mail message to root every day at 00:15 complaining about the fact that a daemon has a negative user number. I do not know *why* 'cron' complains or even cares about the user ID for 'in.fingerd'. I *do* know that it is rather annoying finging this message in one's mailbox every morning. Aside from this nuisance message, 'nobody' works just fine when assigned as the user name for 'finger' in the /etc/inetd.conf file. ============================================================================== ARPA, BITNET: trn@aplcomm.jhuapl.edu UUCP: {backbone!}mimsy!aplcomm!trn Q: ??? A: Next to Larkspur ==============================================================================
guy@auspex.UUCP (Guy Harris) (11/24/88)
> Under SunOS 4.0, however, 'cron' sends a mail message to root every day at > 00:15 complaining about the fact that a daemon has a negative user number. > I do not know *why* 'cron' complains or even cares about the user ID for > 'in.fingerd'. "cron" neither complains nor cares. "cron" merely dutifully collects the standard output and error of "cron" jobs and, if any such output was produced, mails it to the owner of the "crontab" file containing the job (under the presumption that they are to be considered the owner of the cron job itself). The intent behind this is that if any "cron" job finds a problem of some sort and complains about it, its complaints will be heard instead of being sent down the bit bucket. This may take some getting used to, but it is a win; I'll bet there were several "cron" jobs that weren't *quite* doing what the administrator expected them to do, and that were only discovered not to work correctly when people upgraded to an OS running a "cron" based on the S5R2 or later "cron". Since it appears at 00:15, it is probably due to the following "crontab" line: 15 0 * * * /usr/etc/sa -s >/dev/null which chomps through the process accounting file and summarizes it. That command will, in fact, complain if a UID from the accounting file is found that doesn't correspond to one that it found in the password file. Unfortunately, SunOS currently declares "uid_t" to be unsigned, 4.3BSD-style (and, indirectly, S5-style - both system use unsigned UIDs), but have negative UIDs for things like "nobody" and treat UIDs as signed types in some other places. This will probably be fixed in a future release (negative UIDs will go away, and "nobody" will become 65534), but at present it slightly confuses "sa". The actual message "sa" produces isn't about negative user numbers or daemons; it is Preposterous user id, 65534: ignored which is, as stated, a complaint that there's no user "65534" in the password file. >I *do* know that it is rather annoying finging this message >in one's mailbox every morning. Try 15 0 * * * /usr/etc/sa -s 2>&1 >/dev/null | egrep -v 65534 or, perhaps even better, replace "65534" in the example with '^Preposterous user id, 65534: ignored$' which will strip out *only* the particular line in question, not just any line with "65534" in it. The latter appeared to work when I tried it.