PDA

View Full Version : SLES 11 SP3 /dev/null or /dev/urandom with wrong perms 0660 after reboot



gurucubano
23-Mar-2016, 08:29
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

jmozdzen
23-Mar-2016, 14:37
Hi Matthias,

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

Regards,
Jens

gurucubano
23-Mar-2016, 14:58
Hi Matthias,

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

Regards,
Jens

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

jmozdzen
23-Mar-2016, 16:29
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

gurucubano
29-Mar-2016, 14:03
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

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

jmozdzen
29-Mar-2016, 15:12
Hi Matthias,


As often, the problem was a mixture of two or more. [...]
We can close the thread.

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

Regards,
Jens