Andy Polyakov, on August 16. 2000, wrote:
: > : See? He gets ---------- file owned by root in /his/dir and can't do a
: > : thing about it afterwards but to *delete* the damn file (as chown works
: > : only one way for non-privileged users, you can give away, but not get
: > : back).
: >
: > Well, I don't want think about scenarios like that last one :)
:
: http://www.iki.fi/~sjl/ you refer to in your signature says "Job title:
: Chief engineer, SSH2." I think it's your *duty* to think of all possible
: scenarios including this one. And I don't think you're in position to
: refer to systems permitting giveaways as "dumb" either. It's a
: *legitimate* option which might be dictated by the way the users of that
: particular system conduct their daily business.
You misunderstood me in that. I was referring to a scenario, where you
_could_ get the file back after giving it to another user.
And my job title doesn't deny me my opinions, mind you that. I think
you are rather impolite in dictating what I should think about a
system. And legitimate or not, filegiveaways are still dumb and a
source for so many break-ins in the past. ssh can't do anything to
prevent possible security problems with those. Can you say ".rhosts"?
(of course, that attack isn't used that often anymore, but it is still
a threat)
I try, to the best of my ability, to make our software robust and
secure. To my knowledge, it is.
: > : Given that the protocol transfers numeric ids, not user names? If those
: > : two systems has distinct accounting systems (which is spelled as "users
: > : have different numeric ids in different systems"), then answer is
: > : "definitely not." Indeed, why would I want to give away Sami's files to
: > : Anne if they happened to have same numeric ids on the invlolded systems?
: >
: > Of course, you're right in your example. That doesn't mean that the
: > chown()in doesn't have it's uses. For example, I have the same UID in
: > every distinct network I use (and other users have too).
: ^^^^^^^^^^^ Question is how many?
: The least we know you do, I don't, you know some who do, I know some who
: don't. Then recall how the discussion started. The fellow transfered a
: file from Windows to Unix. When you figure out how to create an NT
: account with a given RID, I'd love to hear about it:-)
This is beating a dead horse, because I already granted that you were
right in this.
: ... and rewarded the lazy ones. And denied the experienced users the
: right to control their umask (as .cshrc is the spot to set it) during
: file transfers (provided that they filter chown arguments through it as
: I suggested in the patch I've posted few days later). How about that?
: It's also damn real-life story.
As I am not speaking for SSH Communications Security here, I can say
"too bad, use a real shell". csh and tcsh don't make a distinction
between interactive and non-interactive mode, which is bad (by
distinction, I mean how you can configure the shell to
act). Compromises, compromises... You've got to live with
them. There's so many variants, we can't deal with all. This was the
"least pain" approach. If, as a sysadmin, you don't like my approach,
you can always disable it, if someone complains. And then take care of
the users who have stuff like "echo Hyv�� p�iv��" in their .cshrc...
: P.S. BTW, why I still haven't got it through the list?
Don't know, my later posts haven't got through either.
--
[[EMAIL PROTECTED] -- Sami J. Lehtinen -- [EMAIL PROTECTED]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp http://www.ssh.com/]
