Bug 116317 (IT_56615) - symbolic links have invalid permissions
Summary: symbolic links have invalid permissions
Alias: IT_56615
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact:
Depends On:
Blocks: 156320
TreeView+ depends on / blocked
Reported: 2004-02-19 23:58 UTC by Cheryl L. Southard
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 14:19:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
diff -u (660 bytes, patch)
2004-12-07 07:40 UTC, keith young
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:663 qe-ready SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 6 2005-09-28 04:00:00 UTC

Description Cheryl L. Southard 2004-02-19 23:58:57 UTC
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):

How reproducible:

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
-> ../init.d/firstboot
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
-> ../init.d/mdmonitor
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

Additional info:

Comment 1 Bill Nottingham 2004-03-16 23:32:57 UTC
I don't see this here. Did you install the packages with an odd umask?

Comment 2 Cheryl L. Southard 2004-06-09 05:32:49 UTC
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

Comment 3 Chris Hollowell 2004-06-15 19:45:05 UTC
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:
< # 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?

Comment 4 John Kerbawy 2004-08-23 03:41:03 UTC
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.

Comment 7 Scott White 2004-12-02 14:06:18 UTC
Any news on this bug?  It was logged in Feb but is still causing us
problems 9 months down the line?

Comment 8 keith young 2004-12-07 07:40:09 UTC
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

Comment 9 keith young 2004-12-07 07:54:18 UTC
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?

Comment 12 keith young 2004-12-09 07:48:35 UTC
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...

Comment 26 Ernie Petrides 2005-07-13 23:40:27 UTC
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).

Comment 31 Red Hat Bugzilla 2005-09-28 14:19:57 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.