From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922 Description of problem: The symbolic links created from the initscripts rpm have arbitrary permissions. As far as I can tell, symbolic link permissions are never used, but the only valid ones that I can ever produce when using the "ln -s" or "chmod" command are always lrwxrwxrwx. This is a very minor annoyance, but since I use tripwire to check permissions on my files, it is causing red flags to pop up. For example, one system I installed has the permissions: ls -al /etc/rc.d/rc0.d/S00killall lrwxrwxrwx 1 root root 17 Feb 19 15:23 /etc/rc.d/rc0.d/S00killall -> ../init.d/killall* But another system has ls -al /etc/rc.d/rc0.d/S00killall lrwxr-xr-x 1 root root 17 Feb 19 08:56 /etc/rc.d/rc0.d/S00killall -> ../init.d/killall On RedHat 8.0, all symbolic links in those directories were lrwxrwxrwx Version-Release number of selected component (if applicable): initscripts-7.31.9.EL-1 How reproducible: Always Steps to Reproduce: 1.ls -al /etc/rc.d/rc0.d 2. 3. Actual Results: snipit of output: lrwxr-xr-x 1 root root 18 Feb 19 08:57 K92iptables -> ../init.d/iptables lrwxr-xr-x 1 root root 19 Feb 19 08:58 K95firstboot -> ../init.d/firstboot lrwxr-xr-x 1 root root 15 Feb 19 08:56 K95kudzu -> ../init.d/kudzu lrwxr-xr-x 1 root root 16 Feb 19 08:57 K96pcmcia -> ../init.d/pcmcia lrwxr-xr-x 1 root root 19 Feb 19 08:56 K99mdmonitor -> ../init.d/mdmonitor lrwxr-xr-x 1 root root 15 Feb 19 08:56 K99mdmpd -> ../init.d/mdmpd lrwxr-xr-x 1 root root 23 Feb 19 08:57 K99microcode_ctl -> ../init.d/microcode_ctl lrwxr-xr-x 1 root root 17 Feb 19 08:56 S00killall -> ../init.d/killall lrwxr-xr-x 1 root root 14 Feb 19 08:56 S01halt -> ../init.d/halt Expected Results: All the symbolic link permissions should be lrwxrwxrwx Additional info:
I don't see this here. Did you install the packages with an odd umask?
Since all previous permissions on symbolic links include Redhat 8 were lrwxrwxrwx, I consider the lrwxr-xr-x to be the oddball one. I just used kickstart to freshly install a system and several of the symbolic links are lrwxr-xr-x. For example, I just kickstart installed a RHEL 3 WS Update 2 computer and the permissions on the symbolic link /usr/sbin/ksconfig are lrwxr-xr-x A computer that I installed at RHEL 3 WS Update 1, then later I ran "rpm -Fvh redhat-config-kickstart-2.3.22-1.noarch.rpm" contains the same symbolic link but with permissions lrwxrwxrwx I don't know WHAT umask kickstart uses to install the oddball machine. When I run "rpm -Fvh <pkg>" by hand, my umask is always 0022. Does the umask really make a difference? I
When one creates a symbolic link on an ext3 filesystem while running the 2.4.21-15.ELBOOT kernel, the permissions on the link are set to 755, rather than the usual 777. This appears to be the case for (at least) the -9.0.1.ELBOOT, -9.0.3.ELBOOT and -4.ELBOOT kernels as well. Symlinks created on ext2 filesystems have appropriate permissions. As far as I can tell, there is no direct way of changing the permissions on symbolic links from userland (there's an lchown() function in the C library, but no lchmod() procedure). If one looks through linux-2.4.21-15.EL/fs/ext3/namei.c, it appears that the permissions for newly created symbolic links on an ext3 filesystem are defined as a constant (777 [S_IRWXUGO]) in the ext3_symlink() function: static int ext3_symlink (struct inode * dir, struct dentry *dentry, const char * symname) { handle_t *handle; struct inode * inode; int l, err; l = strlen(symname)+1; ... if (IS_SYNC(dir)) handle->h_sync = 1; inode = ext3_new_inode (handle, dir, S_IFLNK|S_IRWXUGO); It is therefore fairly strange that symlinks are having their mode bits set to 755. Since the problem is only occurring under the BOOT kernel (2.4.21-15.EL doesn't have this problem), I diff'd kernel-2.4.21-i386-BOOT.config with kernel-2.4.21-i686.config, looking for changes to the EXT3 options: 1615c1613 < # CONFIG_EXT3_FS_XATTR is not set --- > CONFIG_EXT3_FS_XATTR=y 1619c1617 < # CONFIG_EXT3_FS_POSIX_ACL is not set --- > CONFIG_EXT3_FS_POSIX_ACL=y Perhaps this is occurring because ACL/XATTR support wasn't included in the BOOT kernel's ext3 module?
I can confirm this problem as well. A co-worker was having the same issue with Tripwire, tracked it down to an installation issue, and then we narrowed it down to being the BOOT kernel.
Any news on this bug? It was logged in Feb but is still causing us problems 9 months down the line?
Created attachment 108022 [details] diff -u Only apply umask to files which are not symlinks. Similar patch applies to fs/ext3/acl.h in 2.6
When CONFIG_EXT3_FS_POSIX_ACL is not set, ext3_init_acl() is an inline function defined in ext3_acl.h. This applies umask to a new inode without checking to see if it's a symlink (whereas the acl code treats symlinks specially). The same thing applies in 2.6.9 (except it's in fs/ext3/acl.h). I've tested this by recompiling the BOOT ext3 module and using it to replace the ext3.o in netstg2.img. I'm prepared for someone to tell me that this is the wrong thing to do, but it seems to work for us :-). Remind me now why we pay fo that bizzarely expensive support contract?
Andreas Gruenbacher has pointed out that umask is already taken care of at the VFS layer, so whilst the above attached patch "works" OK, the correct "fix" is actually just to get ext3_init_acl() to return 0 in all cases rather than making a special case for symlinks...
A fix for this problem has just been committed to the RHEL3 U6 patch pool this evening (in kernel version 2.4.21-32.11.EL).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-663.html