The udev-056 ebuild was installed when I updated yesterday. Shortly thereafter, I was unable to ssh out of my box - complaints about PRNG not being seeded. Turns out devices such as /dev/{random,urandom,null,zero} had permissions set incorrectly after I ran udevstart. Rebooting didn't help. These four nodes had permissions of root:root 660. They should be 664/666, depending. Point being average joe user couldn't send script output to /dev/null nor could ssh work. I can't guarantee that I've listed all of the device nodes that had screwy permissions, but the bug prevented ALL X terminal emulators from working. The permissions file looks like everything should be fine. It appears that udev is simply ignoring it. I added =sys-fs/udev-056 to my packages.mask, updated, portage took it down to udev-045, and everything works well. Reproducible: Always Steps to Reproduce: 1. Upgrade to udev-056 2. run udevstart or reboot 3. be frustrated Actual Results: The permissions were screwy, as detailed above. Expected Results: udev should have created all the nodes with the permissions from the permissions file. Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3, glibc-2.3.5-r0, 2.6.11.7 i686) ================================================================= System uname: 2.6.11.7 i686 Intel(R) Pentium(R) M processor 1200MHz Gentoo Base System version 1.6.11 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 13 2005, 03:55:35)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.9.5, 1.5, 1.8.5-r3, 1.7.9-r1, 1.6.3, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium-m -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium-m -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.UTF-8" LC_ALL="C" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi aim alsa apm audiofile avi berkdb bitmap-fonts bonobo cdparanoia cdr crypt cups curl directfb divx4linux dvd emboss encode fam fbcon ffmpeg flac foomaticdb fortran gdbm gif gpm gtk gtk2 gtkhtml guile ieee1394 imagemagick imlib java javascript joystick jpeg libg++ libwww mad maildir mikmod mmx motif mozilla mozsvg mp3 mpeg msn ncurses nls offensive ogg oggvorbis opengl oscar oss pam pcmcia pcre pdflib perl png pnp python qt quicktime readline sdl sndfile speex spell sse sse2 ssl svg svga sysfs sysvipc tcpd tiff truetype truetype-fonts trusted type1-fonts usb vcd vorbis wifi win32codecs xml xml2 xmms xv xvid yahoo zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, LINGUAS
Created attachment 58852 [details] /etc/udev/permissions.d/50-udev.permissions This is the permissions file I'm using. You'll note that everything looks good for the four device nodes I mentioned.
I did an etc-update. It only changes /etc/udev/scripts/cdsymlinks.sh and /etc/udev/scripts/ide-devfs.sh
ChangeLog <snip> *udev-051 (03 Feb 2005) 03 Feb 2005; Greg Kroah-Hartman <gregkh@gentoo.org> +files/udev.conf.post_050, +udev-051.ebuild: update to 051 release. This fixes (or should) the firmware oops. Also, please note that the .permissions files are now gone! If you had custom ones in the past, you need to move that logic into the .rules files (if not, you'll just get root only access to the devices, so it's not a security issue...) </snip> Comment #1: That file is no longer supposed to be there and is not parsed by udev at all - delete the whole directory (/etc/udev/permissions.d/) and reboot as noted in the ChangeLog, otherwise only root will have access to the devices.
Ok. That's great. I found that by deleting /etc/udev/rules.d/50-udev.rules before upgrading the package that everything works great. The new default file wasn't overwriting the old one (a good practice, I would say). Don't you think it's a problem that there is such a major syntactical change and no automated system for correcting it? Either etc-update should offer to change 50-udev.rules to reflect the new location of permissions, or something should happen letting the user know that they need to delete their old file first. I would imagine simply upgrading is going to break a lot of boxes in the near future (seems it's already broken quite a few). I don't mean to offend the developers - I greatly appreciate your work. It just seems a bit premature to unmask a package if its installation is going to break things for the standard user, requiring intervention like what I had to do to get it working. It's obviously not a technical bug with udev, but I believe that something with the way the ebuild is written should be changed. Consider that the bug. If you totally disagree, well, you've got the power to close the bug again ;)
No, portage never deletes anything under CONFIG_PROTECT path. Also, it seems to me that you still don
No, portage never deletes anything under CONFIG_PROTECT path. Also, it seems to me that you still don´t understand the nature of the problem - it´s permissions.d directory and the files in there that are causing this "bug" - rules.d/50-udev.rules will be upgraded if you choose so when running etc-upgrade, that is not the problem. Would it be any better if there was a warning while emerging the new version?
Actually, udev-056 completely disregards the permissions.d directory. It's not causing any problems. The issue is that in udev-045, used the permissions file. Now in 056, that file is obsolete. So, anyone who upgrades is not going to be able to use /dev/random, et al as a user because what was once configured in permissions is now configured in 50-udev.rules. Everyone is going to have to make MAJOR changes to 50-udev.rules, whether through etc-update or hand edits, in order to keep their system running properly. etc-update did not offer to update 50-udev.rules for me. It made no indication that a newer version of the file was available. I can't say I completely understand the way configuration files are updated by default. At any rate, like I mentioned, etc-update only reported updates to /etc/udev/scripts/cdsymlinks.sh and /etc/udev/scripts/ide-devfs.sh. I think that's the biggest problem. If I had known there was a newer configuration file, I'd have checked the diffs and let it overwrite/merge with the old file. I was never presented with that option. Should I have been? At the very least, I agree that a warning is in order. Include instructions for copying over the new 50-udev.rules file.
OK, I give up. I never had any problems with upgrading from 045 to 056 when following the changelog and ebuild instructions. Last time I did this yesterday, but I also have upgraded on a number of systems long time before 056 actually went stable. You have probably some non-standard setup or whatnot.. I _never_ had to mess with anything in 50-udev.rules manually. I also think that your understanding wrt the ChangeLog entry regarding permissions.d is incorrect.
Are the permissions set up inproperly in the current 50-rules file? If so, please let me know (a patch would be great.)
I need info on what device nodes are set inproperly.
The permissions in the default 50-udev.rules file that is part of the package is good. The permissions are fine. The problem is that after relocating where permissions are taken care of, it doesn't try to update the 50-udev.rules file in /etc/udev/rules.d/. My old file was left completely intact (the file that relied on permissions being spelled out in permissions.d). etc-update did not present the 50-udev.rules file as a file in need of updating. This would be resolved if etc-update reported that the configuration file needs to be changed. As it is, etc-update makes no such report, and so my 50-udev.rules file does not get changed when upgrading to udev-056. Thus, it tries to use the udev-045 configuration and fails. I think this may be less of a problem with udev itself and more of a problem with the way updates to configuration files are handled.
Comment #10: Well, that must your local problem, work on over 20 machines here...
Any ideas about what would be preventing etc-update from offerring an update to 50-udev.rules?
I do not, it does that for me.
I'd recommend to modify the einfo messages! Please point out that it is dangerous to run udevstart or reboot if people haven't run etc-update before! I did 1. emerge -u udev 2. udevstart - as you recommended via einfo 3. etc-update and suddenly everything went crazy. My qmail had TSL problems, my sshd had problems, etc. I haven't changed anything in any permission-files - I only recently switched to udev.
