umask and man pages

[Eric Coulter_1]

I have a script that checks for world writable files. It's simply enough in form and function. However, I have noticed that files previously set using the default umask of 077 are showing up later with no changes to inodes, file size, creation dates and times, or location. Specifically, I see this with the man pages. For example,

Previously,
-rw------- 1 root sys 23838 May 20 09:34 swlist.1m

Yesterday,
-rw-rw-rw- 1 root sys 23838 May 20 09:34 swlist.1m

I have been told that HP-UX handles man page creation in a wholly different way than Solaris. Which is fine for me, but I need proof of justification for my audit department. When they audit us they will need to know why these files are set to world writable.

Thanks,

Eric

[Pete Randall]

Eric,

What version of HP-UX are we dealing with here?

My 11i systems show:

ll /usr/share/man/man1m.Z/swlist.1m
-r--r--r-- 1 bin bin 17627 Nov 14 2000 /usr/share/man/man1m.Z/swlist.1m


Pete

[James R. Ferguson]

Hi Eric:

Clearly something (someone) is changing the permissions. You may be able to find out "when" by looking at the inode change timestamp:

# ls -lc swlist.1m

Regards!

...JRF...

[Caesar_3]

Hello!

I don't know how Solaris works but man page
don't need write permisions, and the creation
it's when you install some program it put
the man pages with permissions that it set.

Caesar

[Steven E. Protter]

It would be interesting to know why man pages are a security problem.

If a malicious person did choose to change them, it would not affect system operation in any way. It might lead a sysadmin astray I suppose.

To the core of your question, they would appear to be world writable, because HP-UX does not install in a secure way, like say Linux. HP-UX is an OS that has to be made secure, its not secure out of the box.

After installing a system, you should make sure the root user has a umask of say 022, change the permissions on these files and they won't change back.

The scenario where manuals are not readable by regular users is ridiculous(see your original permissions). The man pages exist to help people user the command functionality that you(root) give them.

BTW, my man pages are all read only even to root, so the problem may most likely be an incorrect umask on the root user which owns the manuals.

I ran Bastille on my system and it handled permissions on files such as man pages.

Summary: There is no reason for man pages to be read-write. Fix the umask, change the permissions to read only and move on with life. There is nothing to explain to the auditors, you merely need to fix it.

I doubt there is some cron job messing with these permissions, but you should check.

Regards,

SEP

[A. Clay Stephenson]

Man pages should be 444 so this is strange from the getgo. You mention creation times but there is no way in UNIX (except by accident) to know when a file was created. The ctime is actually the time the files's permission or mode was changed. I would display the modification times and change times and see if you see some kind of pattern. It appears that someone has doe a wholesale chmod.

[Bruno Vidal]

Hi,
It depend on which directory you see that.
If permission change in man* then someone is changing permission and you have a security pb.
If you see that in cat* then it is normal, check man man:

Within each of these directories, man searches in the cat*.Z
subdirectories, the man*.Z subdirectories, the cat* subdirectories,
and the man* subdirectories. man*.Z and man* directories contain
nroff(1)-compatible source text for the entries. cat*.Z and cat*
directories contain the formatted versions of the entries. man*.Z and
cat.Z directories contain entries in compressed form. Files in these
directories are uncompressed by uncompress (see compress(1)) before
being processed for printing or display.

So in cat* directories, it is aformatted copy of man pages, so the umask depend of the user that do the man command.

Cheers.

[Umapathy S]

Eric,

My machine looks like this

$ find . -name "swlist*" -print -exec ll {} \;
./cat1m.Z/swlist.1m
-rw-rw-rw- 1 root sys 16691 Jan 13 1998 ./cat1m.Z/swlist.1m
./man1m.Z/swlist.1m
-r--r--r-- 1 bin bin 12127 May 30 1996 ./man1m.Z/swlist.1m


man* dirs will have the ntroff compatible source of the man pages while cat* dirs will have the formatted versions. These will be created when someone first access that man page. Check which location you are dealing with. check man pages of man.

HTH,
Umapathy

[Eric Coulter_1]

It might help to clarify.

Internal auditors tend to be control freaks. That explains the need to secure man pages.

Outside of that, I do correct the permissions on the files I find, which is the reason for the script.

As for the Previously, I incorrectly listed it as -rw------- and it should have been -r--r--r-- (444).

There are no cron jobs affecting these. As for the creation date and time I misused vocabulary. My thought was on last changed and it translated to creation. That was my fault.

I don't particularly care one way or the other on man pages. I guess having them writable might allow a malicious person to confuse or mislead a user by editting the information.

Either way, I just wanted to be able to explain it.

I was told that executing man on a command recreates that man page file. Which should by default create it as 027 umask. However, as I tested this I could not recreate the effects. Another oddity is that I noticed ownership sometimes changes as well, which supports the "create on demand" man pages. Patent anyone?

Eric

[A. Clay Stephenson · Accepted solution]

Okay Eric, now I understand your problem. When anyone does a man regardless of umask a file is created (if it doesn't already exist) in the cat*.Z directory with 666 permissions. Let's say that you are doing a man ls. Man looks to see if it already has a formatted image in cat1.Z (ls.1) if so then that is used. If cat1.Z/ls.1 does not exist then man1.Z is used, uncompressed, nroffed and displayed and then the formatted image is compressed and stored in cat1.Z.

If this really bugs you then simply remove (or rename) the catX.Z directories and no new files will be formatted and stored for faster retrievel. Be aware that some man pages are only delivered in their formatted versions but this practice is not encouraged. I would rename the directories and see if you have any problems and after a few days remove the catX.Z directories.


I suspect the reason for the 666 mode setting is so that when a change to a man page is needed, anyone can format and replace it from the manX.Z originals.