Permissions changed in /dev/null in every boot

[_kai_]

Hi buddies,

I have this annoying issue, when I type my login and password in kdm, the screen blinks to black and then I get back to the kdm login screen.

Doing a little research in my computer, I found the permissions of /dev/null have changed to 600. When I change the permissions to the correct ones, I mean, 666, I was able to enter to my kde session.

But I have to do the change permission thing in every boot of my computer!

Thanks for this wonderful piece of software called [k]ubuntu.

[Ante Karamatić (ivoks)]

What's the output of:

grep -sr null /etc/udev/*

?

[_kai_ (gpayo)]

Wow, that was fast!

There is the command's output:
/etc/udev/rules.d/40-permissions.rules:KERNEL=="null",
 MODE="0666"

Thanks!

 --- Ante Karamatić <email address hidden> escribió:

> What's the output of:
>
> grep -sr null /etc/udev/*
>
> ?
>
> ** Changed in: Ubuntu
> Importance: Untriaged => Medium
> Status: Unconfirmed => Needs Info
>
> --
> Permissions changed in /dev/null in every boot
> https://launchpad.net/bugs/53040
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

[Ante Karamatić (ivoks)]

OK, so udev sets null permissons corectly. Could you add output of:

RUNLEVEL=`runlevel | cut -d" " -f2`
echo $RUNLEVEL
egrep -sr "chmod.*null" /etc/rc$RUNLEVEL.d/* /etc/rc.local

Thanks.

[Dennis Kaarsemaker (dennis)]

Is /dev/null also a regular file at that point?

[_kai_ (gpayo)]

The output of the command is:

# RUNLEVEL=`runlevel | cut -d" " -f2`
# echo $RUNLEVEL
2
# egrep -sr "chmod.*null" /etc/rc$RUNLEVEL.d/* /etc/rc.local
/etc/rc2.d/S19cupsys: chmod 3775 /usr/share/ppd/custom 2>/dev/null || true

Nothing inusual, I think... :(

[_kai_ (gpayo)]

Yes, It is a regular file:

# ls -l /dev/null
crw------- 1 root root 1, 3 2006-05-31 03:33 /dev/null

And after I issued the chmod 666 /dev/null command:

# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2006-05-31 03:33 /dev/null

Thanks!

[Dennis Kaarsemaker (dennis)]

Do you perhaps use a vpn client?

[_kai_ (gpayo)]

No, I do not use a Virtual Private Network.

The only thing I have customized are:

1. My wireless pci card (rt2500) which drivers I have
downloaded and compiled myself.

2. The drivers of my Nvidia video card

 --- Dennis Kaarsemaker <email address hidden>
escribió:

> Do you perhaps use a vpn client?
>
> --
> Permissions changed in /dev/null in every boot
> https://launchpad.net/bugs/53040
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

[elinar (elinar)]

I also have this same issue. I changed the permissions manually in rc.local at every boot, but it stil affects portions of the boot cycle. particularly, it happens before logcheck runs, as I get an email containing the following

Cron <logcheck@otherland> if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi
/usr/sbin/logcheck: line 533: /dev/null: Permission denied
/usr/sbin/logcheck: line 619: /dev/null: Permission denied

It would be nice to fix. Is /dev/null generated by udev only? or is it hard coded into the /dev/ folder to support early boot mechanisms before udev starts?

[_kai_ (gpayo)]

Hi...

elinar, have you resolved this problem? Have you seen any light? I still have this issue.

Thanks!

[Ante Karamatić (ivoks)]

elinear, please add output of:

ls -dl /etc/rcS.d/*
and
ls -dl /etc/rc2.d/*

[elinar (elinar)]

Ok so I have attached those and also rc5, which is the level I use in inittab for booting into gui.

[elinar (elinar)]

On Sunday 06 August 2006 04:52, Ante Karamatić wrote:
> elinear, please add output of:
>
> ls -dl /etc/rcS.d/*
> and
> ls -dl /etc/rc2.d/*
I have added those to the bug report. Thank you for your attention :)
--
PLease dont CC me from mailing lists.

[Ante Karamatić (ivoks)]

Is this still an issue?

[_kai_ (gpayo)]

Sorry, but I get another job and therefore I can tell
you. :(

--- Ante Karamatić <email address hidden> escribió:

> Is this still an issue?
>
> --
> Permissions changed in /dev/null in every boot
> https://bugs.launchpad.net/bugs/53040
> You received this bug notification because you are a
> direct subscriber
> of the bug.
>

____________________________________________________________________________________
¡Descubre una nueva forma de obtener respuestas a tus preguntas!
Entra en Yahoo! Respuestas.
http://es.answers.yahoo.com/info/welcome

[turncoat (uskokovic)]

I had this problem on 2 of my machines. One was upgraded from 6.10 to 7.04 and other is fresh install of 7.04.
I solved problem in rc.local, but I'm interested what's the problem...
Can I help identify the problem?

[Ante Karamatić (ivoks)]

Sure! Attach output of:

grep -sr null /etc/udev/*

egrep -sr "chmod.*/dev/null" /etc/rcS.d/*

and

egrep -sr "chmod.*/dev/null" /etc/rc2.d/*

[turncoat (uskokovic)]

Here it is... Like the others...
Before restart, /dev/null was 666.
Now when it is 600, when i shut down and boot livecd, after mounting my root partition in /mnt i find that
root@ubuntu:~# ls -l /mnt/dev/null
crw-rw-rw- 1 root root 1, 3 Apr 15 11:49 /mnt/dev/null

When I shut it down, and start in single user mode, I find that
root@la-02:~# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 April 15 13:49 /dev/null

and after logging out, and continuing runlevel 2 it stays crw-rw-rw,
but if i restart again and start runlevel 2 the normal way, I get the crw------- situation again...
Zajebancija... :)

I even managed to login right after upstart started my getty, and continued to start other services.
The /dev/null was 666, but after every service got started, it changed back to 600

Since there are many services on this machine (student's machine for learning linux servces), I will turn them all off later this evening, and report what happened...

[Ante Karamatić (ivoks)]

turncoat wrote:

> Since there are many services on this machine (student's machine for
> learning linux servces), I will turn them all off later this evening,
> and report what happened...

Start it in single user mode, go to /etc/rc2.d/ and start service one by
one. After every service, check status of /dev/null. Then, when it
changes, report last two services you've started.

P.S. Keep comments in english :)

[turncoat (uskokovic)]

I don't have access to that machines now, but I can tell you that I started normal, got rw-------, and went telinit 1 and it went ok: rw-rw-rw-
When I went normal and said: killall5 and /etc/init.d/single, it was unchanged: rw-------. I'll try more things tomorrow... Very strange bug/feature :)

[turncoat (uskokovic)]

When I start runlevel 2 I get 600 permissions, but when I switch to runlevel 1
/dev/null gets proper 666 permissions. So I restarted to get 600 again, and then
started stopping one by one service to see when does the change happen:

for file in `ls -1 /etc/rc1.d/*|grep -v README|grep -v S90single`;
 do echo $file >> /tmp/null.log;
  ls -l /dev/null >> /tmp/null.log;
  sh $file stop;
  ls -l /dev/null >> /tmp/null.log;
  echo "___________" >> /tmp/null.log ;
 done

File /tmp/null.log got this content:
 K01gdm
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K01kdm
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K01usplash
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K09apache2
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K11anacron
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K11atd
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K11cron
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K19cupsys
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K19hplip
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K19samba
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20acpi-support
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20apmd
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20apport
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20avahi-daemon
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20console-setup
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20dbus
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20hotkey-setup
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20kde-guidance
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20keyboard-setup
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 ___________
 K20makedev
 crw------- 1 root root 1, 3 2007-04-15 13:49 /dev/null
 crw------...

[Ante Karamatić (ivoks)]

Almost all files in /lib/udev/devices have 0600 permissions, except directories and kmem. So, 0600 on udev in there is alright.

This is udev bug. Have you created your own udev rules? Did you install prerelease of Feisty and then upgrade it when it was released (your /dev/null is older than Feisty)?

Thank you for extensive testing!

[turncoat (uskokovic)]

No, I have not created, nor modified udev rules. It was not prerelease of Feisty. One machine was 6.10 and upgraded to 7.04 and other one is fresh install of 7.04.
The one that was upgraded is pretty much clean machine, since it serves like backup-via-ssh server. It doesn't have any of the testing services like the other one machine.

Anyway, I don't see any harm having relaxed permissions on /lib/udev/devices/null .

Any ideas what else to examine?

[DeeKey (privateinf)]

This is for shure UDEV problem!
I have the same one :(
some info here: http://osdir.com/ml/os.freebsd.devel.hackers/2002-10/msg00088.html

Try to fix it by einstalling the UDEV package

sudo apt-get install --reinstall udev

[DeeKey (privateinf)]

Sorry, the above solution does not help :(
I don´t know how to fix it. See the bug which is close to it. Maybe it can help?
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/63031

[Dave (dave-netexpertise)]

I had the same issue on Fedora Core though.
I noticed some lines were commented out in /etc/rc.d/rc.sysinit:

----------------------------------------------------------------------------------
if [ -f /etc/udev/udev.conf ];then
        . /etc/udev/udev.conf
fi

[ -x /sbin/start_udev ] && /sbin/start_udev
----------------------------------------------------------------------------------

Uncommenting them gives the proper rights on /dev/null.

Dave
----
http://www.netexpertise.eu

[DeeKey (privateinf)]

I managed to recover from this problem by reinstalling coreutils, libc6 and dpkg:

sudo apt-get install --reinstall coreutils libc6
sudo apt-get install --reinstall dpkg

But still the question remains what had happened? What was the problem?

[Launchpad Janitor (janitor)]

[Expired for udev (Ubuntu) because there has been no activity for 60 days.]

[Aaron Swartz (aaronsw)]

I'm getting this problem after upgrading from dapper to hardy.

[Yves Lavoie (yves-lavoie-ing)]

I also have the same problem on hardy.

[Yves Lavoie (yves-lavoie-ing)]

And it was related to libsane-extras.rules! Removing this one brought back the proper permissions on /dev/null.