SGID man

[solar () FALSE COM (Solar Designer)]

> > Let me give an example: because man is setuid to the man uid, the binary
> > must be owned by uid man.
>
> That is why it should be setgid to man, and not setuid. sgid has the
> same benefits in added privilegies for the user to read or write in
> special directories, but is less obvious how to elevate these
> privilegies to get more privilegies.

I wouldn't normally post this, but while we're on the topic...
There's an ancient problem with SGID man that I keep seeing on
various systems.  For example, on Red Hat 5.2:

[[ghost@alice ghost]$ ls -l /var/catman/cat1/id.1.gz
ls: /var/catman/cat1/id.1.gz: No such file or directory
[[ghost@alice ghost]$ man id
Formatting page, please wait...
[[ghost@alice ghost]$ ls -l /var/catman/cat1/id.1.gz
-r--rw-r--   1 ghost    man           806 Aug  1 06:14 /var/catman/cat1/id.1.gz
[[ghost@alice ghost]$ chmod u+w /var/catman/cat1/id.1.gz
[[ghost@alice ghost]$ echo haha | gzip > /var/catman/cat1/id.1.gz
[[ghost@alice ghost]$ chmod u-w /var/catman/cat1/id.1.gz

The next day, another user wants to know how to use "id":

[[luser@alice luser]$ man id

Guess what they will see.

Solutions?  We could change the permissions on those directories from
775 or 1777 (that's what I've seen on various systems) to 770, so
that group man is always required.  However, doing so would break
things, as the group is (and should be) dropped for many operations.
Some changes to the way man works would be required to support such
restricted permissions.  A workaround could be to preformat all the
man pages as root.  Finally, we could move to a SUID man, making the
binary immutable (non-portable, not backup friendly).  I don't like
any of these.

In my opinion, it is time to stop storing preformatted pages.  It is
no longer worth the risk.  CPUs got faster, man pages are the same.

Signed,
Solar Designer