Joerg Schilling wrote:
> "Garrett D'Amore" <gdamore at sun.com> wrote:
>
>
>> What about a third option: leave the existing Sun rmt in place, and
>> deliver just star? I'm trying to figure out what problem Shillix
>> /etc/rmt is trying to solve for us, and I confess, that I'm having a
>> hard time seeing it. (The original case indicated interest due to
>>
>
> Please read PSARC 480/2004
>
> In addition, you may read the man pages of both rmt implementations....
>
> You may also check the various discussions we had already to find a list of
> reasons.
>
> J?rg
>
Okay, but some of the information in 2004/480 is quite stale now.
Quoting from that case:
The problems with the current rmt are that:
- it is slow
- it is moderately buggy
- the documentation is noticeably out-of-sync with the code
- it has no concept of security beyond what the system itself
enforces (i.e., if you can get it running as root, you can
read or write any file on the machine)
The 1st item may remain a concern still. However, it was presented as a
claim, without any quantitative analysis behind it, nor citing any
requests from customers indicating that this was a problem.
(Furthermore, if the problem is CPU bound, its possible that CPU speed
increases have basically eliminated this from being a concern for most
customers. I'm not sure.)
However the 2nd item seems not to have much drive behind it -- I've been
told that sustaining costs on rmt are basically non-existent at this
point. I don't know if that means that nobody is asking for
fixes/improvements, or just that Sun isn't spending there. The implicit
claim is that Joerg's rmt is less buggy than Sun's.
The 3rd item is easily fixed, and takes far less effort/risk than
introducing a whole new rmt.
The 4th item is what concerns me architecturally here. I don't
understand -- if all that rmt does is protect the system from users who
have rexec/rsh/ssh access, then why wouldn't the user just spawn a shell
instead? It seems to me that there is no value, and maybe even negative
benefit (false sense of security) in access control decisions made after
sshd/rshd/rexecd has spawned the user program. (In which case I would
also agree that no audit requirement exists.) Am I misunderstanding?
-- Garrett
