In article [EMAIL PROTECTED] you write:
[...]
This raises a question with me. If I understand how debian works, even when
a fixed base pkg gets updated on a debian system, this error with user nobody
will still be there since it won't overwrite the passwd file. This isn't the
best example of this
Hello,
I just changed su nobody to su root. I can run it manually now as
root so I assume cron should run it OK next time around.
Dont do this. The entries in the find.codes database are public, therefore
there should be no informatiuon stored normal users are unable to see (i.e.
filenames in
This bug was in the passwd file from the base package.
It can be fixed by replacing the nobody line in /etc/passwd with this entry:
nobody:*:65534:65534:nobody:/dev/null:
Hope that helps.
Susan Kleinmann
[EMAIL PROTECTED]
I have already bug-reported this and it's being worked
/etc/cron.daily/find looks like this:
#! /bin/sh
#
# cron script to update the `find.codes' database.
#
# Written by Ian A. Murdock [EMAIL PROTECTED].
su nobody -c cd / updatedb 2/dev/null
but the nobody entry in /etc/passwd looks like this:
nobody:*:65534:65534:nobody:/tmp:/dev/null
and it
[EMAIL PROTECTED] wrote:
Rick Is this a problem with the cron job from the findutils package or the
Rick passwd file from the base package?
With the passwd file. There is a : missing at the end of the nobody entry.
It should be
nobody:*:65534:65534:nobody:/dev/null:
Has this
This bug was in the passwd file from the base package.
It can be fixed by replacing the nobody line in /etc/passwd with this entry:
nobody:*:65534:65534:nobody:/dev/null:
Hope that helps.
Susan Kleinmann
[EMAIL PROTECTED]
6 matches
Mail list logo
