Andy Polyakov, on August 16. 2000, wrote:
: > This has absolutely no impact on security. The sftp-server is running
: > on the user's privileges. I agree it shouldn't by default try to
: > change the files ownership, but that only leads to an error
: > message.
:
: You're missing the point. Some systems *permit* chown to another uid
: even for non-priviledged users (and most systems can be configured by
: changing a kernel parameter to permit this operation). Excerpt from my
Ahem. *lights blowtorch*
Again, by default we probably shouldn't be trying to do that. But if
the system is so dumb, that it allows file giveaways for non-roots, why
should filexfer care (note: it is not designed to do any kind of
access control checks, it just tries, to the best of it's ability, to
accommondate to the clients wishes). I'm doing a tool for myself, too,
here, and for me the "-p" has always been ok, so it has stayed as it is.
: Solaris box is the *best* case scenario and doesn't have any drastic
: side effects causing any error messages. The fellow who originally
: posted the problem report would see something like following on his
: computer:
:
: unlink("/my/dir/a.txt") = 0
: open("/my/dir/a.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
: fchmod(3, 0) = 0
: fchown(3, 0, 0) = 0
: fchmod(3, 0100666) Err#1 EPERM
: utime("/my/dir/a.txt", 0xEFFFF94C) Err#1 EPEPM
: fchmod(3, 0100666) Err#1 EPERM
: utime("/my/dir/a.txt", 0xEFFFF94C) Err#1 EPERM
: close(3) = 0
:
: 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 :)
: It's not "only an error message," it's frustration over not being
: able to access just transferred file.
Ok, I was wrong.
: > If you were root and you were copying a file in a system, and gave a
: > command like "cp -p ~user_a/archive /system/archive" wouldn't you want
: > the uid of the file to remain same?
:
: 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). Now, if I
want to (as root) move user A's files from machine foo to machine bar,
the ownership of the file will remain constant.
I agree though, that this behaviours use is limited.
: Now if we take into consideration that common accounting system in most
: cases means common file system (otherwise why would one want to have
: common accounting system in first place?), then why would one favor scp
: for cp? Bottom line. "chown" shouldn't be there at all and I find it
: hard to believe that people will have hard time accepting it (as they're
: already *used* to it). Then why do you worry about root so much?
: There're 2^32-2 other users and root will survive in either case...
You've got a good point here.
: We can even go one step further. Is chmod(0) really necessary? I
: perfectly understand why you wanted it there in first place... I just
: want to point out that it's a perfect way to screw up (at least Solaris)
: ACLs in case there were any set.
How do you change file permissions on that kind of solaris without
messing the ACL? I'd like to fix this. The chmod(0) (as a concept)
won't be going anywhere.
: Shall you wait for a bug report (from a
: real customer) and introduce another option? Options, options,
Har. I listen to real users, customer or not.
: options... But do they help? Do they really improve the *quality* of the
: product? Or do you simply weave a rope for users who feel like hanging
: themselves today?
That's a really nice philosophical question. If possible, I solve the
problem without changing the command interface. If not, it will be
another option...
: Or simply feed marketing department with something to
: shout about?
Marketing usually doesn't know the value of power in
configuration. They shout the buzzwords and acronyms, you should know
that :)
: Introduction of -f option for those whos .cshrc files
: generate output is another sad example (in my opinion). The problem is
: as old as Unix and users should (and some even do) know (how to fix) it.
: Now SSH comes and tells "kids, when you do drugs, wear a hat" instead of
: "don't do drugs."
LOL :) Well, you can take it that way. Real-life story: users
complaining, why doesn't scp and sftp work? Support points out the
problem, but more and more users are asking the same
question. Putting it to the FAQ doesn't help, as users don't read
it. So, I get fed up, and introduce that "option" there (which you
never need to touch).
: Anyway. Bottom bottom line question. Does file *access* policy belong in
: file *transfer* protocol at all?
Yes, because the transfer handles setting the access in the way the
user wants. But, I'm bending your way here, and *something* will be
done to the problem. Most probably, filexfer will retain the
functionality (because you can build loads of things on top of that,
not only file _transfer_ applications), but the programs using it
will be fixed.
: > Sending mail to our support-addresses has a meaning,
:
: So was posting to [EMAIL PROTECTED] in pre-2.x days...
Are you saying it doesn't have a meaning today? C'mon.
: OK, I admit I miss
: those days... On the other hand (you may call me a dreamer) I sincerely
: believe that open discussion works better than mailing to somebody who
: expects 9 of 10 messages to be RTFM-kind of questions and moreover have
: to actually answer those 9 questions... So I gonna keep on posting to
: [EMAIL PROTECTED]:-) See ya...
When complaining here about a problem (in our ssh2), you
might as well add the [EMAIL PROTECTED] etc. address :)
--
[[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/]
