Wrong permissions of /dev/null (XUbuntu 15.10)

After running update today and rebooting the OS lightdm would not start. After some debugging I noticed that /dev/null (and some other /dev files) do not have adequate permissions (compared to another Ubuntu box I have) - e.g. 'others' could not read nor write /dev/null.

After 'chmod a+rw /dev/null /dev/urandom /dev/random /dev/ptmx' lightdm started up. Of course this is not reboot persistent so I need to put this in some /etc/rc.* to make it stick - which I do not want to!

Anyone knows why this started to happen? IOW, it worked up till today for me.

[SOLVED] I had custom buggy udev rules that would set certain /dev entries to 0600!

As Rinzwind properly mentioned, /dev/null is created on every boot , but specifically every device including /dev/null is created by MAKEDEV script, which is referenced in several /etc/init scripts as shown bellow:

xieerqi:$ sudo grep -iR "makedev" /etc 2 > /dev/null                                                                                  
[sudo] password for xieerqi: 

    xieerqi:$ sudo grep -iR "makedev" /etc 2> /dev/null                                                                                   
    [sudo] password for xieerqi: 
    /etc/init/mounted-dev.conf: /sbin/MAKEDEV std fd ppp tun
    /etc/init/mounted-dev.conf:     /sbin/MAKEDEV console
    /etc/init.d/udev:create_dev_makedev() {
    /etc/init.d/udev:  if [ -e /sbin/MAKEDEV ]; then
    /etc/init.d/udev:    ln -sf /sbin/MAKEDEV /dev/MAKEDEV
    /etc/init.d/udev:    ln -sf /bin/true /dev/MAKEDEV
    /etc/init.d/udev:    create_dev_makedev

The /sbin/MAKEDEV and /sbin/makedev are the same script, which have in the header settings for all the devices and their respective permissions. In particular, on makedev my system creates the null device with $public permissions:

makedev null c 1 3 $public

At the top the public is defined as public=" root root 0666"

You should be able to open this script and modify the permissions as necessary or verify they are not altered in any way.

However, if they are unaltered, it is strongly recommended to report this behavior as bug, and for your own convenience probably switch to gdm for the time being.