Alright so the other day I go to jokingly cat /dev/zero > /dev/hda (as a normal user) so I can go paste the permission denied as a joke, forgetting that it's /dev/sda on my computer (SATA.) Oddly enough, it works, and I quickly ctrl-c wondering what happened. A 260mb file named "hda" inside /dev created by a normal unprived user. I do some investigation into the matter. ls -ld /dev drwxrwxrwt 17 root root 3500 Apr 3 01:52 /dev /dev is marked rwxrwxrwt. I wonder why? Someone else was just configuring udev in a chat and theirs is rwxr-xr-x. The difference? They're using ramfs. I am using tmpfs. Tmpfs's default permissions are apparently 1777. Adding an -o mode=755 to the line in /sbin/rc should probably fix this, but I'm not even sure if it's a problem or not. The potential risk, seems to be that you could potentially max out your memory AND swap (seeing as tmpfs can swap unlike ramfs) by doing this, which would not be very good at all. Another thing is that there's no max limit option passed to mount when mounting tmpfs, so that also allows this to happen, though of course if the first issue is fixed only root could potentially cause this. Switching to ramfs makes the permissions rwxr-xr-x for me, so it's not just this other person with different permissions. Of course it's not very likely someone would do this, and a normal user cannot remove or edit existing things in /dev, just create new, so this isn't a super-major issue. However, it does seem like this is incorrect behavior. I'm running a pure udev system with udev 056 and baselayout 1.11.10-r5. /dev/shm potentially has this same problem as it's using tmpfs and has the same permissions, but I'm not really sure what permissions /dev/shm is supposed to have.
not a udev issue
try this: # ebuild /usr/portage/sys-apps/baselayout/baselayout-1.11.11-r3.ebuild clean unpack compile install # ls -l /var/tmp/portage/baselayout-1.11.11-r3/image/
$ ls -l /var/tmp/portage/baselayout-1.11.11-r3/image/ total 24 drwxr-xr-x 2 root root 4096 May 12 23:41 bin drwxr-xr-x 2 root root 4096 May 12 23:41 dev drwxr-xr-x 9 root root 4096 May 12 23:41 etc drwxr-xr-x 3 root root 4096 May 12 23:41 lib drwxr-xr-x 2 root root 4096 May 12 23:41 sbin drwxr-xr-x 5 root root 4096 May 12 23:41 usr it appears that dev is fine there...
oh yeah I should probably mention that I'm using baselayout 1.11.11-r3 now, I usually keep my system up to date. And I have rebooted since then, so /dev has been mounted using the latest baselayout, this problem still persists.
portage does not change permissions on existing directories so you will have to fix them yourself ... try doing `chmod 755 /dev` and `chmod 1777 /tmp` then reboot and see if permissions are still screwed
Tried here and yup, it reverts back to 1777 after reboot.
sounds good
how is this resolved? he said it reverts back to 1777 after reboot, which indeed it does. I tried it.
what is 'it' ? we were talking about two dirs (dev and tmp), /tmp is *supposed* to be 1777
I don't get why /tmp is even being mentioned. My /tmp never had incorrect permissions in the first place. I was talking about tmpfs, however. My /dev permissions remain 1777 after reboot, despite the chmod, which I figured would happen, seeing as /dev is being mounted with tmpfs, which is not having it's permissions set.
i thought you mentioned /tmp somewhere you neglected to provide `emerge info` like the bug report page said to so i dont know what kernel you're running ...
# emerge info Portage 2.0.51.21-r1 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-ck7-r1 i686) ================================================================= System uname: 2.6.11-ck7-r1 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.11 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.7 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" 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=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://gentoo.mirrors.tds.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ http://gentoo.oregonstate.edu" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="x86 X aalib acpi alsa apm artworkextra avi bitmap-fonts cdr crypt cups curl dvd dvdr emboss encode esd fam ffmpeg flac foomaticdb fortran gdbm gif gimpprint gnome gpm gstreamer gtk gtk2 guile imagemagick ipv6 java jpeg ldap libg++ libwww lirc mad mikmod mmx mmx2 mozilla mp3 mpeg ncurses network nls nptl nptlonly nvidia offensive ogg oggvorbis opengl oss pam pango pdflib perl png ppds python quicktime readline real rtc samba sdl slang spell sse sse2 ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts userlocales v4l v4l2 vorbis win32codecs xine xinerama xml2 xv xvmc zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS i only mentioned tmpfs, if you read my initial report you'll notice I state that adding -o mode=755 to the mount line in /sbin/rc fixes this. Also, I mention that /dev/shm potentially has the same issue, as both are mounted using tmpfs, which seems to have default permissions that are somewhat insecure...
/dev/shm is supposed to be world accessible i'll update /sbin/rc to mount /dev by default with mode=755 as you suggested, and throw in some noexec/nosuid while i'm at it the odd thing is that /dev is 755 on a bunch of my machines while some others are 1777 even though they are all mounted tmpfs oh well, better to assume insanity and force sane settings
I'm curious now if perhaps the chmod had no effect because /dev was already mounted with tmpfs, and all the chmod did was change tmpfs's permissions. Maybe I should try booting to a livecd and seeing what /dev's permissions are? I'll do this now infact...
nope, unmounted /dev permissions were correct, so it's definitely tmpfs causing this. It's very odd that it'd be different on some systems than others if all are using tmpfs, only thing that would make sense is kernel differences... here's the relevant mount output just for reference... udev on /dev type tmpfs (rw)
with some more investigation i notice my laptop which uses tmpfs has the correct permissions...yet this box doesn't...weird...It's using ck4 not ck7...i'm going to upgrade the kernel now and see if it changes...I doubt it will though, as checking my emerge log shows the time i reported this bug I was probably using ck3...unless 3 causes it and 4 doesn't and 7 does...I doubt it. Somethings weird is going on here...
Comment #9: "It" is /dev of course, I miss how /tmp is relevant here... I have reproduced this on three Gentoo boxes so there must be a bug somewhere. It does not happen with ramfs.
so maybe I was wrong...after updating my laptops kernel to ck7-r1 now /dev is showing up wrong...but I sort of doubt it's one of con's changes that causes this, I'm guessing it's one of the point-point-point releases or whatever they're called which con includes in his latest releases...
# mkdir /mnt/test # mount --bind / /mnt/test # ls -la /mnt/test/ | grep dev drwxr-xr-x 2 root root 120 Apr 16 17:43 dev Running gentoo-sources-2.6.11-r6
ok, fixed in cvs, will be in baselayout-1.11.12
