> > > 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:54:40 PDT