/dev/null or /dev/urandom with wrong perms 0660 after reboot

SUSE Linux Enterprise Server SLES Configure-Administer
1

Hello,

From time to time we run into the problem that /dev/urandom (and also /dev/null) has wrong perms after system boot

sisis@sunny1:> ls -l /dev/urandom crw-rw---- 1 root root 1, 9 22. Mär 10:23 /dev/urandom

and causing all kinds of, for example SSL problems. The fix is simple, but why happens this at all? I checked already
all start scripts we provide and which are called at boot time without any luck. Don Google shows, that we are not allone with this, but
I have found only pointers to Ubuntu systems.

I have seen this inhouse on some of our SLES 11 development servers and some day ago as well on a server of one of our customers.

Any ideas? Thanks in advance

Matthias

2

Hi Matthias,

have you checked for according definitions in /etc/permissions.d/? Or maybe there’s a hit in /etc/permissions…

Regards,
Jens

3

[QUOTE=jmozdzen;31999]Hi Matthias,

have you checked for according definitions in /etc/permissions.d/? Or maybe there’s a hit in /etc/permissions…

Regards,
Jens[/QUOTE]

Hello,

no luck:

fgrep null /etc/permission*/* /etc/permission* /etc/permissions:/dev/null root:root 666 /etc/permissions:/lib/udev/devices/null root:root 0666 /etc/permissions:/var/lib/named/dev/null root:root 0666

This would also not explain, why it is only sometimes (very seldom, 2-3 a yearü, IIRC).

Thanks

matthias

4

Hi Matthias,

can you pinpoint when this happens? It might be worth to correlate this with package installations (i.e. via /var/log/zypp/history) to see if some post-install script causes these changes.

Regards,
Jens

5

[QUOTE=jmozdzen;32009]Hi Matthias,

can you pinpoint when this happens? It might be worth to correlate this with package installations (i.e. via /var/log/zypp/history) to see if some post-install script causes these changes.

Regards,
Jens[/QUOTE]

As often, the problem was a mixture of two or more. The /dev/urandom modification was caused by a wrong udev-rule. The /dev/null was more sofisticated.
I identified the start script (launched at system boot as user root); the script, which brings up one of our application servers, could even modify the
permissions of /dev/null when started by a normal user; this is ofc impossible for this proc. But, the proc was doing syslog with facility local5 and
someone configured in /etc/syslog-ng/*.conf as target file /dev/null; a strace shows that the syslog-ng was changing the perms of the file:

# cat /tmp/syslog-ng.tr ... 3088 open("/dev/null", O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_NONBLOCK, 0640) = 11 3088 fcntl(11, F_GETFD) = 0 3088 fcntl(11, F_SETFD, FD_CLOEXEC) = 0 3088 fchown(11, 0, 4294967295) = 0 3088 fchown(11, 4294967295, 0) = 0 3088 fchmod(11, 0640) = 0

We can close the thread.

Thanks, Matthias

6

Hi Matthias,

[QUOTE=gurucubano;32051]As often, the problem was a mixture of two or more. […]
We can close the thread.[/QUOTE]

I do have weird ideas many times, but I wouldn’t have come close to that problem source :wink: Thanks for reporting back and I’ll keep that syslog side-effect in mind!

Regards,
Jens