On Tue, Sep 11, 2012 at 06:15:02PM +0100, Alan Dennis wrote: > Requested files attached. All standard, except experimental addition of > LOCK_MODE to /etc/default/tmpfs, which had no effect.
Thanks. I took a look through, but didn't see any obvious explanation for this misbehaviour. > Note that /run/lock is created in /lib/init/mount-functions.sh with > permissions explicitly set to 755 (in mount_lock()). This is correct. However, the next step is either 1) Mounting a tmpfs with the correct mode, or 2) Changing the permissions to the correct mode. You seem to be mounting the tmpfs but without the correct perms. Could you possibly try the following: % sh $ . /lib/init/tmpfs.sh $ echo $LOCK_MODE 1777 $ echo $LOCK_OPT ,size=5242880,mode=1777 When mounting the tmpfs, $LOCK_OPT are the mount options in use. As you can see, the default is 1777. I tested all the various combinations extensively, so if this isn't working for you, I would be very interested to understand why. > The permissions are still 755 when the system has booted and a shell is > available. There is nothing to say if the permissions have changed to 1777 > and then been changed back again, but this seems unlikely as changing > mount_lock() to create /run/lock with 1777 results in /run/lock having perms > 1777 at the end of the boot. > > It looks as though the permissions specified when the /run/lock is created > remain and are not later chmod'd by LOCK_MODE. This is correct. /run/lock is a mountpoint when using a tmpfs as you have indicated you are, so when the tmpfs gets mounted on /run/lock, the mode specified in the mount options will get used since it masks the permissions of the underlying mountpoint. As mentioned above, it looks like this is likely due to the wrong (or no) mode option being passed to mount. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org