Bug 116317 (IT_56615)
| Summary: | symbolic links have invalid permissions | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Cheryl L. Southard <cld> | ||||
| Component: | kernel | Assignee: | Stephen Tweedie <sct> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.0 | CC: | cww, hollowec, petrides, poelstra, tao | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | RHSA-2005-663 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-09-28 14:19:57 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 156320 | ||||||
| Attachments: |
|
||||||
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 |
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: