This one has me stumped.
At 2:20AM /dev/null’s permissions are changing to a restrictive setting that allows root access but not normal user access.
I am not seeing anything obvious in cron or /etc/permissions* or /etc/udev. And
device path not found
Suggestions?
On Wed, 19 Jan 2011 23:06:02 +0530, rexecd
<rexecd@no-mx.forums.opensuse.org> wrote:
>
> This one has me stumped.
>
> At 2:20AM /dev/null’s permissions are changing to a restrictive setting
> that allows root access but not normal user access.
>
> I am not seeing anything obvious in cron or /etc/permissions* or
> /etc/udev. And
>
> # udevadm info --path=/dev/null
> device path not found
>
> Suggestions?
>
did you update anything before that happened? i don’t know if it’s
related, but after my last zypper up i couldn’t access my own IMAP server
anymore–except with pine. this error message appeared whenever another
client tried to contact dovecot:
(there wasn’t any dovecot update involved.) after a while i opened
apparmor config. via YAST and found that it. was enabled–even though i’ve
never used it, and certainly didn’t enable it. after disabling appar.
everything worked as usual, i.e., other IMAP clients could access the
server.
this happened early in the session and probably other things would have
failed, too. didn’t check the permissions of /dev/null though…
–
phani.
Interesting. AppArmor was enabled (but not doing anything, if the empty report dirs in /var/log/apparmor/ are any indication).
I’ve disabled it, and we’ll see what happens.
Still, I am looking for a better understanding of what mechanism exactly is changing these permissions (from 666 to 640). Puzzling stuff, and an opportunity to learn something.
On Thu, 20 Jan 2011 01:06:01 +0530, rexecd
<rexecd@no-mx.forums.opensuse.org> wrote:
> Still, I am looking for a better understanding of what mechanism
> exactly is changing these permissions (from 666 to 640). Puzzling
> stuff, and an opportunity to learn something.
in that update i had quite a few rpm output statements that permissions
were checked and in some cases corrected. there were also messages about a
seg-fault caused by apparmor functions; i assume because i never used it
and didn’t create or enable any profiles. but on my machine /dev/null
permissons are still 666.
–
phani.
Disabling AppArmor didn’t fix the problem. Anyone?
When /dev/null permissions are wrong, bad things happen, notably procmail bouncing mail (critical OS file missing. Command output: procmail: Error while writing to “/dev/null” ). I have this in root cron for now:
chmod go+rw /dev/null
which
I could turn off mail for a minute then, but that’s not fixing anything just mitigating damage.
rexecd wrote:
> This one has me stumped.
>
> At 2:20AM /dev/null’s permissions are changing to a restrictive setting
> that allows root access but not normal user access.
>
> I am not seeing anything obvious in cron or /etc/permissions* or
> /etc/udev. And
>
> # udevadm info --path=/dev/null
> device path not found
>
> Suggestions?
I never knew about this command. FWIW, the correct syntax appears to be
$ udevadm info --path=/devices/virtual/mem/null --query=all
or
$ udevadm info --name=null --query=all
It doesn’t show anything on my machine that looks likely to help though.
Maybe you could write a rule to get more info.
As another not-thought-through suggestion, would using dnotify on /dev
from 2:19 to 2:21 tell you anything?
Cheers, Dave
I agree with pahanisvara that an update must have occurred to change the permissons. Do you run a logwatch or can you check the output from your last update?
On my 11.2 system /dev/null permissions is 0666.
stat /dev/null
##
## reset manually for now until you trace the change, as I said most likely occurred during an update.
##
sudo chmod 0666 /dev/null
There’s nothing in the logs to ID the actor here; they just note the subsequent failures related to /dev/null. I do not have system updates automated, and still like clockwork, at 2:20AM BAM!
I just turned auditing on for chmod system calls.
No automatic updates, a cron job or run-parts at 2:20a?