> On Fri, Mar 10, 2006 at 10:09:28PM +1000, Russell Kliese wrote:
>> > let me just say one more time, if you can't run updatedb as nobody,
>> > the problem is a permissions problem... you indicated that it fails
>> > whether the nice line is there or not.
>>
>> I guess I didn't explain things too clearly. It _doesn't_ fail when I
>> don't use nice.
>>
>> The following line fails (with "pam_open_session: Permission denied" in
>> the auth.log):
>>
>> cd / && nice updatedb 2>/dev/null
>>
>> If I change the line to the following it doesn't fail:
>>
>> cd / && updatedb 2>/dev/null
>>
>> Also, updatedb runs as root. The updatedb drops down to the nobody user
>> (via su) to run the find command.
>
> it is very likely that you have a default nice
> value either on the host or for your guest which
> the guest tries to raise without success
>
> (for some reason debian thinks that it is nice
> to have nice values for certain things :)
>
> try to check your current nice value, as root
> inside the guest, and check the logs (pam) what
> it tries to set the nice value to ...
I logged into both the host and the guests and it looks like the nice
values are zero for both root and the nobody user. When suing to nobody,
there are no messages reported in the pam logs apart from the usual:
secure:/# nice
0
secure:/# su nobody -s /bin/bash
nobody@secure:/$ nice
0
The logs include:
Mar 11 00:25:53 secure su[861]: + pts/1 root:nobody
Mar 11 00:25:53 secure su[861]: (pam_unix) session opened for user nobody
by (uid=0)
>> >> >On 3/9/06, Russell Kliese <russell@eminence.com.au> wrote:
>> >> >
>> >> >
>> >> >>I have a problem with the find cron job inside a debian vserver.
>> >> >>
>> >> >>The find cron job runs the updatedb script as follows:
>> >> >>
>> >> >>#! /bin/sh
>> >> >>#
>> >> >># cron script to update the `locatedb' database.
>> >> >>#
>> >> >># Written by Ian A. Murdock <imurdock@debian.org> and
>> >> >># Kevin Dalley <kevin@aimnet.com>
>> >> >>
>> >> >>LOCALUSER="nobody"
>> >> >>export LOCALUSER
>> >> >>if [ -f /etc/updatedb.conf ]; then
>> >> >> . /etc/updatedb.conf
>> >> >>fi
>> >> >>
>> >> >>if getent passwd $LOCALUSER > /dev/null ; then
>> >> >> cd / && nice -n ${NICE:-10} updatedb 2>/dev/null
>> >> >> # cd / && updatedb 2>/dev/null
>> >> >>else
>> >> >> echo "User $LOCALUSER does not exist."
>> >> >> exit 1
>> >> >>fi
>> >> >>
>> >> >>The updatedb script tries to su to the nobody user, but this fails
>> >> with
>> >> >>the following messages logged in /var/log/auth.log
>> >> >>
>> >> >>Mar 10 14:55:02 secure su[26501]: + pts/1 root:nobody
>> >> >>Mar 10 14:55:02 secure su[26501]: (pam_unix) session opened for
>> user
>> >> >>nobody by root(uid=0)
>> >> >>Mar 10 14:55:02 secure su[26501]: pam_open_session: Permission
>> denied
>> >> >>
>> >> >>
>> >> >>If I comment in the line with the # in the above script (and
>> comment
>> >> out
>> >> >>the line above), things work fine (i.e. I don't get the
>> >> >>"pam_open_session: Permission denied" logged in the auth.log). So
>> it
>> >> >>seems to be something to do with nice. Note that even if I remove
>> the
>> >> >>"-n ${NICE:-10}" things still don't work.
>> >> >>
>> >> >>Would enabling CAP_SYS_NICE help in this case even though a lower
>> >> >>priority is being set? Or is there something else causing this
>> >> problem?
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Fri Mar 10 14:29:37 2006