Patrick D. Dowler wrote:

> It seems that there are several choices:
>
> 1.  if system supports the necessary ioctl, you can have session feature and
> privacy   without suid (seems to be the best of all)
>
> 2. if the system doesn't support the necessary ioctl, you can
>
>    a) install normally and not have privacy (can't chown/chmod)
>
>    b) install suid, disable session feature, and have some security by
>        dropping priviledges after chmod/chown'ing the pty - then
>        you get privacy at the expense of sessions, with minimal security
>        problem from suid
>
>    c) install suid, don't drop priviledges, and have session feature
>
> 3. Could you do 2a but set up something like sudo to let users
>     change the priviledges of the pty's they open? Would sudo be
>     any more portable? It seems that to get privacy and sessions, you
>     need the cooperation of the sysadmin in any case...

At least for non-Linux systems. The right way to handle the problem does not
only depend on the OS, but also on the environment. For a single user
workstation (as many Linux installations are), there's not security issue at
all. For a multiuser environment, i cannot expect the sysadmin to run to set
konsole root/suid (and thereby risking to compromize the whole system). I for
one certainly won't do that if i were responsible for a system's security.

Guess the discussion so far was pretty helpful for me. In fact, your posting is
my summary so far. Their might be another way to cope with the other UNIXes,
but in the moment i tend to a such a hybrid solution. I'm waiting for the
outcome of a FreeBSD investigation to learn whether this OS belongs to kind 1
or 2.

Lars