Sami,
> I'm quoting the whole text, as it has been a while this was posted.
>
> Andy Polyakov, on July 14. 2000, wrote:
> : > When my users (including me) try to sftp using the Win-2.2.0.exe
> : > program to a 2.2.0 server, the file that they upload gets the error
> : > below. The file is also given root:root ownership and perms 0000.
> :
> : This is outrageous! Following is (relevant) output from 'truss -p
> : <sftp-server-pid>' on Solaris box:
> :
> : 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) Err#1 EPERM
> : fchmod(3, 0100666) = 0
> : utime("/my/dir/a.txt", 0xEFFFF94C) = 0
> : fchmod(3, 0100666) = 0
> : utime("/my/dir/a.txt", 0xEFFFF94C) = 0
> : close(3) = 0
> :
> : Well, if Solaris whould let 'fchown(3,0,0)' through then I would also
> : get root:root and 0000 perms and the error message... Sometimes I really
> : wonder how do they think... To blindly beleive what a windows box say...
> : How does uid-gid calculated? How does 666 get calculated? I mean in
> : fchmod...
>
> 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
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). It's not "only an error message," it's frustration over not being
able to access just transferred file.
> 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?
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...
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. Shall you wait for a bug report (from a
real customer) and introduce another option? Options, options,
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? Or simply feed marketing department with something to
shout about? 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."
Anyway. Bottom bottom line question. Does file *access* policy belong in
file *transfer* protocol at all?
> Sending mail to our support-addresses has a meaning,
So was posting to [EMAIL PROTECTED] in pre-2.x days... 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...
Andy.
