patchTiger UNIX security tool - Patches: patch #2476, remove the fileutils / LSGROUP...


You are not allowed to post comments on this tracker with your current authentication level.

patch #2476: remove the fileutils / LSGROUP test in the Linux/2/config.

Submitted by:  Ryan Bradetich <rbrad>
Submitted on:  Wed 14 Jan 2004 06:03:51 AM UTC  
Category:  Security test Priority:  3 - Low
Status:  Invalid Privacy:  Public
Assigned to:  Javier Fernandez-Sanguino Peña <jfs> Open/Closed:  Open

Thu 22 Jan 2004 07:25:30 AM UTC, comment #4:

I went back and looked at the bug report in additional detail and think I found the problem:

[This is from the bug report jfs posted.]

> $ dpkg --status fileutils |grep ^Version
> Version: 4.1.10-2
> jfs@hades:/tmp/jfs$ /bin/ls -L -lg -ld /home/aalonso

drwxr-sr-x 6 aalonso 4096 2002-07-17 23:37 /home/aalonso

Notice here that the group is NOT replaced by a number, instead the file owner is plain missing. The above command has one less field then the command below.

> $ dpkg --status fileutils |grep ^Version
> Version: 4.1-10
> jfs@avalon:~$ /bin/ls -L -lg -ld /home/aalonso

drwxr-sr-x 6 aalonso aalonso 4096 jul 17 23:37 /home/aalonso

The problem is the same problem I have run into with RedHat, SuSE, etc. Newer versions of ls do not display the owner if the -g option is given.

Here is the what the man page says about -g for the ls command on newer versions of ls:
-g like -l, but do not list owner

I believe my origional patch is correct for the following reason:

Every place the $LSGROUP is used we are interested in parsing the file owner. So specifying the -g option is either ignored (older versions) or does not display the file owner.

removing the -g makes the ls command work correctly in all cases.

Ryan Bradetich <rbrad>
Project Member
Wed 21 Jan 2004 11:29:42 PM UTC, comment #3:

Interesting... Because I actually tested this case (Debian woody :))

I am running debian woody in a chroot environment:

dpkg --list | grep fileutils
ii fileutils 4.1-10 GNU file management utilities

ls --version
ls (fileutils) 4.1

# ls -l /etc/passwd
-rw-r--r-- 1 root root 820 Nov 19 16:38 /etc/passwd

# ls -lg /etc/passwd
-rw-r--r-- 1 root root 820 Nov 19 16:38 /etc/passwd

(BTW .. thanks for the link to the bug report ... interesting read!)

Here is the SuSE case that is failing:
# cat /etc/SuSE-release
SuSE Linux 8.1 (i386)

# ls --version
ls (fileutils) 4.1.11

# ls -l /etc/passwd
-rw-r--r-- 1 root root 898 Nov 3 2003 /etc/passwd

# ls -lg /etc/passwd
-rw-r--r-- 1 root 898 Nov 3 2003 /etc/passwd

The RedHat was RedHat 7.1 and you have already applied a patch to fix that :)

$ ls --version
ls (GNU fileutils) 4.0.36

Quite a pickle we have here ... I will re-read through the bug report and play some more. Will post if I find anything .

Ryan Bradetich <rbrad>
Project Member
Wed 21 Jan 2004 06:18:41 PM UTC, comment #2:

Well, the -g switch was necessary in the latest Debian (which used fileutils (package version 4.1-10) did have issues. You can find the full summary at

I think this should be kept, but maybe it should be restricted to apply when LXDISTRIBUTION = "debian".

I'll probably revert this patch. Sorry for the late response.... In any case, GNU's fileutils are to blame, can you pinpoint what precise fileutil versions you had on RedHat/SuSE that spewed the problem ('ls --version' would be enough)

Javier Fernandez-Sanguino Peña <jfs>
Project AdministratorIn charge of this item.
Tue 20 Jan 2004 09:28:17 PM UTC, comment #1:

Committed to cvs HEAD on: 01/20/2004.

Ryan Bradetich <rbrad>
Project Member
Wed 14 Jan 2004 06:03:51 AM UTC, original submission:

This patch forces the LSGROUP variable to just "-l". The prevsious version performed a version check on fileutils and set LSGROUP="-lg" if the version was betwee 4.0 and 4.10.

This has caused problems with RedHat in the past and is currently causing problems with SuSE. I believe this check causes more harm then actual good because of the following reasons:

1. I believe the check/comment is wrong. The only linux box I have access to that fixs into this category is on a RedHat 6.2 systems and the output of "-l" and "-lg" is the same.

$ ls --version | grep fileutils
ls (GNU fileutils) 4.0p

$ ls -l /etc/shadow
-r-------- 1 root root 946 Aug 28 20:09 /etc/shadow

$ ls -lg /etc/shadow
-r-------- 1 root root 946 Aug 28 20:09 /etc/shadow

2. When the check goes wrong (as in the cases I found with RedHat and SuSE) it looks like:

$ ls -l /etc/shadow
-r-------- 1 root root 835 Oct 18 12:00 /etc/shadow

$ ls -lg /etc/shadow
-r-------- 1 root 835 Oct 18 12:00 /etc/shadow

which screws up checks dependant upon the output of ls.

If anyone knows of a reason why we should keep the -g then I feel the test should check for cases where the -g is needed and then add the -g option.

Ryan Bradetich <rbrad>
Project Member


Attached Files
file #6764:  linux-config.patch added by rbrad (768B - application/octet-stream - Patch to remove the filetils / LSGROUP test.)


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.


Please enter the title of George Orwell's famous dystopian book (it's a date):



Follow 6 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
01/21/2004 jfs StatusDone => Invalid
    Assigned torbrad => jfs
    Open/ClosedClosed => Open
01/20/2004 rbrad StatusNone => Done
    Open/ClosedOpen => Closed
01/14/2004 rbrad Attached File- => Added linux-config.patch, #2513

Back to the top

Powered by Savane 3.3