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):
Steps to Reproduce:
1.ls -al /etc/rc.d/rc0.d
Actual Results: snipit of output:
lrwxr-xr-x 1 root root 18 Feb 19 08:57 K92iptables ->
lrwxr-xr-x 1 root root 19 Feb 19 08:58 K95firstboot
lrwxr-xr-x 1 root root 15 Feb 19 08:56 K95kudzu ->
lrwxr-xr-x 1 root root 16 Feb 19 08:57 K96pcmcia ->
lrwxr-xr-x 1 root root 19 Feb 19 08:56 K99mdmonitor
lrwxr-xr-x 1 root root 15 Feb 19 08:56 K99mdmpd ->
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 ->
lrwxr-xr-x 1 root root 14 Feb 19 08:56 S01halt ->
Expected Results: All the symbolic link permissions should be lrwxrwxrwx
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
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)
struct inode * inode;
int l, err;
l = strlen(symname)+1;
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:
< # CONFIG_EXT3_FS_XATTR is not set
< # CONFIG_EXT3_FS_POSIX_ACL is not set
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]
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.