Results 1 to 6 of 6

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

Hybrid View

  1. #1

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

    Hello,

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

    Code:
    sisis@sunny1:> ls -l /dev/urandom
    crw-rw---- 1 root root 1, 9 22. Mr 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. Re: /dev/null or /dev/urandom with wrong perms 0660 after re

    Hi Matthias,

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

    Regards,
    Jens
    From the times when today's "old school" was "new school"

    If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below...

  3. #3

    Re: /dev/null or /dev/urandom with wrong perms 0660 after re

    Quote Originally Posted by jmozdzen View Post
    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:

    Code:
    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. Re: /dev/null or /dev/urandom with wrong perms 0660 after re

    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
    From the times when today's "old school" was "new school"

    If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below...

  5. #5

    Re: /dev/null or /dev/urandom with wrong perms 0660 after re

    Quote Originally Posted by jmozdzen View Post
    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:

    Code:
    # 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. Re: /dev/null or /dev/urandom with wrong perms 0660 after re

    Hi Matthias,

    Quote Originally Posted by gurucubano View Post
    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
    From the times when today's "old school" was "new school"

    If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below...

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •