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.

Submitter:  Ryan Bradetich <rbrad>
Submitted:  Wed 14 Jan 2004 06:03:51 AM UTC
Category:  Security test Priority:  3 - Low
Status:  Invalid Privacy:  Public
Assigned to:  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>
Group 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>
Group 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>
Group administrator
Tue 20 Jan 2004 09:28:17 PM UTC, comment #1: 

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

Ryan Bradetich <rbrad>
Group 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>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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


There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


Follow 6 latest changes.

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

Back to the top

Powered by Savane 3.12