Bug 297941 - Problem creating directories with only numbers as name.
Summary: Problem creating directories with only numbers as name.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: coreutils
Version: 4.0
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
: ---
Assignee: Ondrej Vasik
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-20 11:43 UTC by Madan Thapa
Modified: 2008-01-17 20:03 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-17 18:49:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Madan Thapa 2007-09-20 11:43:43 UTC
Description of problem:
============================================
Problem creating directories with only numbers as name.

Version-Release number of selected component (if applicable):
==================================================================
root@server [~]# cat /etc/redhat-release 
Red Hat Enterprise Linux ES release 4 (Nahant Update 5)

root@server [~]# uname -a
Linux server.integrityserver.net 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT
2007 i686 i686 i386 GNU/Linux
root@server [~]# 


How reproducible:
======================

root@server [~]# mkdir 1
mkdir: cannot create directory `1': No such file or directory
root@server [~]# mkdir 12
mkdir: cannot create directory `12': No such file or directory
root@server [~]# mkdir 1a2
root@server [~]# 


  
Actual results:
======================
mkdir: cannot create directory `1': No such file or directory


Expected results:
======================
should be able to create a directory

Additional Info:
==================
root@server [~]# ll $(which mkdir)
-rwxr-xr-x  1 root root 25060 Sep 19 15:46 /bin/mkdir*
root@server [~]# rpm -qf $(which mkdir)
coreutils-5.2.1-31.6
root@server [~]# 
root@server [~]# mount -a
root@server [~]# 

FSType = ext3


Thanks

Comment 1 Madan Thapa 2007-09-20 12:07:46 UTC
Sry.. by mistake  Component:mcrypto got selected



Comment 2 Madan Thapa 2007-09-21 13:57:58 UTC
Hello,

Well interesting thing found more details all at once place.....................




On the affected server
###########################

root@server1 [~]# mkdir 1a1
root@server1 [~]# mv 1a1 1
mv: cannot move `1a1' to `1': No such file or directory
root@server1 [~]#



On the affected server
###########################

root@server1 [~]# rpm -vV coreutils | grep mkdir
.......T    /bin/mkdir
........  d /usr/share/man/man1/mkdir.1.gz
root@server1 [~]#



What does this   .......T    mean?



On the good  server
###########################
root@server2 [~]# rpm -vV coreutils | grep mkdir
........    /bin/mkdir
........  d /usr/share/man/man1/mkdir.1.gz
root@server51 [~]#



root@server1 [~]#  file /bin/mkdir
/bin/mkdir: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
root@server1[~]#






root@server1 [~]# strace mkdir 1
execve("/bin/mkdir", ["mkdir", "1"], [/* 23 vars */]) = 0
uname({sys="Linux", node="SERVERNAME_MODIFIED", ...}) = 0
brk(0)                                  = 0x82a2000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=49876, ...}) = 0
old_mmap(NULL, 49876, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa0000
close(3)                                = 0
open("/lib/libselinux.so.1", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340`y\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=56336, ...}) = 0
old_mmap(0x794000, 56176, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x794000
old_mmap(0x7a1000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x7a1000
close(3)                                = 0
open("/lib/tls/libc.so.6", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\236"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1529008, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f9f000
old_mmap(0x5e5000, 1227996, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x5e5000
old_mmap(0x70b000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x125000) = 0x70b000
old_mmap(0x70f000, 7388, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x70f000
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f9e000
mprotect(0x70b000, 8192, PROT_READ)     = 0
mprotect(0x5dc000, 4096, PROT_READ)     = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f9e6c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0xb7fa0000, 49876)               = 0
access("/etc/selinux/", F_OK)           = 0
brk(0)                                  = 0x82a2000
brk(0x82c3000)                          = 0x82c3000
open("/etc/selinux/config", O_RDONLY)   = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=447, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fac000
read(3, "# This file controls the state o"..., 4096) = 447
close(3)                                = 0
munmap(0xb7fac000, 4096)                = 0
open("/proc/mounts", O_RDONLY)          = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fac000
read(3, "rootfs / rootfs rw 0 0\n/proc /pr"..., 1024) = 606
read(3, "", 1024)                       = 0
close(3)                                = 0
munmap(0xb7fac000, 4096)                = 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=48524752, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d9e000
close(3)                                = 0
umask(0)                                = 022
umask(022)                              = 0
mkdir("1", 0777)                        = -1 ENOENT (No such file or directory)
stat64("1", 0xbff86b90)                 = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7d9d000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2528
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0xb7d9d000, 4096)                = 0
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
write(2, "mkdir: ", 7mkdir: )                  = 7
write(2, "cannot create directory `1\'", 27cannot create directory `1') = 27
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such
file or directory)
write(2, ": No such file or directory", 27: No such file or directory) = 27
write(2, "\n", 1
)                       = 1
exit_group(1)                           = ?
Process 3532 detached
root@server1 [~]#


Comment 3 Pete Graner 2007-09-21 14:07:03 UTC
The "T" in the rpm --verify output means the time on the binary differs from
whats in the RPM database. I would remove coreutils and reinstall from a known
good rpm. Then retest.

Comment 4 Madan Thapa 2007-09-21 14:21:13 UTC
Hello,

Can you please advise the steps(even as I am aware of it) with url for a good
source ... do we need to take any precaution before removing coreutils?



root@server [/bin]# cat /etc/redhat-release 
Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
root@server52 [/bin]# uname  -a
Linux SERVER_NAME 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686
i386 GNU/Linux
root@server [/bin]# 


Thanks


Comment 5 Pete Graner 2007-09-21 14:39:31 UTC
(In reply to comment #4)
> Hello,
> 
> Can you please advise the steps(even as I am aware of it) with url for a good
> source ... do we need to take any precaution before removing coreutils?

Good source would be download it from RHN first, or you can get it off the
install CD.

The simplest way would be to run:

rpm -Uvh --force <coreutils pkg>

make sure you get the right rpm filename.

This will cause rpm to overwrite the existing files and update the rpmdb


> 
> 
> 
> root@server [/bin]# cat /etc/redhat-release 
> Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
> root@server52 [/bin]# uname  -a
> Linux SERVER_NAME 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686
> i386 GNU/Linux
> root@server [/bin]# 
> 
> 
> Thanks
> 



Comment 6 Madan Thapa 2007-09-21 14:55:24 UTC
root@server [~]# wget
http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/coreutils-5.2.1-31.src.rpm
--09:49:52-- 
http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/coreutils-5.2.1-31.src.rpm
           => `coreutils-5.2.1-31.src.rpm'
Resolving ftp.redhat.com... 66.187.224.30, 209.132.176.30
Connecting to ftp.redhat.com|66.187.224.30|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4,360,877 (4.2M) [application/x-rpm]

100%[==================================================================================================>]
4,360,877    512.43K/s    ETA 00:00

09:50:03 (523.56 KB/s) - `coreutils-5.2.1-31.src.rpm' saved [4360877/4360877]

root@server [~]# rpm -Uvh --force coreutils-5.2.1-31.src.rpm 
warning: coreutils-5.2.1-31.src.rpm: V3 DSA signature: NOKEY, key ID db42a60e
   1:coreutils              ########################################### [100%]
root@server [~]# rpm -qa | grep coreutils
policycoreutils-1.18.1-4.12
coreutils-5.2.1-31.6
root@server [~]# mkdir 1
mkdir: cannot create directory `1': No such file or directory
root@server [~]# 


Comment 7 Madan Thapa 2007-09-21 14:57:03 UTC
Hi,

It seems now that an OS reload is imminent ?




Comment 8 Pete Graner 2007-09-21 17:03:55 UTC
You got the source RPM not the binary, you have to get it from your media or RHN.

Comment 9 Madan Thapa 2007-09-22 16:17:34 UTC
Installing using the rpm binary from the install CD did not help either... maybe
it got tampered somehow.


Anyways thank you for your help... we have finally decided to go for an OS reload.


You can mark this ID closed.


Thanks Again


Comment 10 Madan Thapa 2008-01-14 20:15:15 UTC
The problem resurfaces on rhel4 server again, is there any resolution to this issue?


Please advise.

Comment 11 Ondrej Vasik 2008-01-17 18:35:02 UTC
Coreutils maintainer changed - current version of RHEL4 coreutils RPM is
coreutils-5.2.1-31.7.el4.<architecture>.rpm . 

Make sure what is returned by rpm -V coreutils. If you will get that your mkdir
binary is modified, force update by latest coreutils rpm. Command mkdir <number>
works correctly with my RHEL4 mkdir binary. 

for i386 architecture(otherwise change architecture):
1)Download that rpm (you may download it from RHN or maybe at some mirror ftp's)
2)rpm -Uvh --force coreutils-5.2.1-31.7.el4.i386.rpm

This should solve your troubles. 
Please specify architecture of the server too in the case that this will not help.

Comment 12 Ondrej Vasik 2008-01-17 18:49:29 UTC
Btw - DO NOT USE severity urgent for such cases ... changing to Medium as this
is seems to be specific customer related problem which is not reproducable on my
side with latest RHEL4 coreutils...

Comment 13 Madan Thapa 2008-01-17 20:03:28 UTC
Hi,


No problem, sorry that I flagged it as severe.

[root@server55 src]# rpm -V coreutils
.M....G.    /bin/su
[root@server55 src]#


I found that is a latest unknown rootkit exploit affected on CentOS and RHEL
servers, not sure if it infects Fedora too.

http://www.cpanel.net/security/notes/random_js_toolkit.html

The rootkit tries to write to /dev/[k]mem


We installed grsec to prevent this. However it is advisable to reload the server
afresh with grsec patch.


id/euid:0/0 gid/egid:0/0
grsec: denied mmap write of /dev/[k]mem by /sbin/ifconfig[ifconfig:401]
uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: denied mmap write of /dev/[k]mem by /sbin/ifconfig[ifconfig:682]
uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: denied mmap write of /dev/[k]mem by /sbin/ifconfig[ifconfig:682]
uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: denied mmap write of /dev/[k]mem by /bin/mount[mount:896] uid/euid:0/0
gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: denied mmap write of /dev/[k]mem by /bin/mount[mount:896] uid/euid:0/0
gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: denied mmap write of /dev/[k]mem by /bin/cat[cat:906] uid/euid:0/0
gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: denied mmap write of /dev/[k]mem by /bin/cat[cat:906] uid/euid:0/0
gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: denied mmap write of /dev/[k]mem by /bin/mount[mount:918] uid/euid:0/0
gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0



Why is it that writing to /dev/[k]mem is allowed by default? Is it a security
hole in RHEL or similar systems or there are good reasons for this to be allowed
in them by default?


Thank you for your time


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