Requested files attached. All standard, except experimental addition of LOCK_MODE to /etc/default/tmpfs, which had no effect.
Note that /run/lock is created in /lib/init/mount-functions.sh with permissions explicitly set to 755 (in mount_lock()). 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. Also: $ mount /dev/root on / type ext4 (ro,noatime,user_xattr,barrier=1,data=ordered) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=23792k,mode=755) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) .... If that helps... -----Original Message----- From: Roger Leigh [mailto:[email protected]] Sent: 10 September 2012 22:25 To: Petter Reinholdtsen; [email protected] Cc: Alan Dennis Subject: Re: Bug#687202: initscripts: /run/lock has perms 0755 instead of 1777 On Mon, Sep 10, 2012 at 10:18:30PM +0200, Petter Reinholdtsen wrote: > [Alan Dennis] > > /run/lock is created with perms 0755 in /lib/init/mount-functions.sh > > : mount_lock(). This prevents non-privileged users from creating > > files/directories in /run/lock. > > In particular, the logcheck package runs as a logcheck user and > > fails to create /run/lock/logcheck. > > Changing mount_lock() to mkdir with --mode=1777 fixes the problem. > > Hm. What did it use to have when it was /var/lock/? My squeeze > installation got this: > > % ls -lad /var/lock/. > drwxrwxrwt 3 root root 4096 10 sep. 10:49 /var/lock/. > % > > I find no file permission mode instructions in > <URL: http://www.pathname.com/fhs/2.2/fhs-5.9.html >. > > But given the use of this directory, I suspect the 1777 mode is > correct, and that this is a regression from Squeeze. The default is still 1777 in wheezy/unstable: LOCK_SIZE=5242880 # 5MiB LOCK_MODE=1777 (from /lib/init/tmpfs.sh) This will be used as a mount option if RAMLOCK=true, or to chmod the directory otherwise, so should be set to 1777 in all use cases. The only cases where the won't happen is where you've created an entry in /etc/fstab which overrides these defaults, or you've added them to /etc/default/tmpfs (which is not documented, because it doesn't make sense to change the mode). If you haven't changed any of the above, and you are using the current version of the initscripts (i.e. you aren't using an old version of /etc/init.d/mountkernfs.sh), then there's clearly a bug here. However, this is working in the general case in my testing of tmpfs and non-tmpfs on /run/lock. If you could provide the contents of /etc/fstab, /etc/default/tmpfs, /etc/init.d/mountkernfs and /lib/init/tmpfs.sh, that would be very helpful. 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
fstab
Description: Binary data
tmpfs
Description: Binary data
mountkernfs.sh
Description: Binary data
tmpfs.sh
Description: Binary data
_______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
