> : 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.
> : 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:-)
> 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.
Again, why root? Isn't *user* capable of transfering the files? Then how
can you be sure that root on foo is also root on bar? On the other hand
you can bet on that the user is *always* the same person on both foo and
bar. You assume way too much... and expect root do all the job for some
reason...
> : 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.
Looks like I have to retract on this. I've mixed it up with another
problem I ran into (well, it was rather late when I wrote yesterday:-).
You would run into a trouble if you set umask to 0 and try to control
access bits through the third argument to open. But you can't lock
yourself away (assuming that chown is out of the picture). But think
DFS... Access bits application gets through stat() are potentially
confusing and tranfering 'em along might have undesired side effects.
One way or another I still stand for the point that generally file
access policy does not belong in file transfer protocol. Per-site vs.
cross-site. It might be against the policy to "wear the hat" on some
site, you see...
> : 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).
... 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.
Andy.
P.S. BTW, why I still haven't got it through the list?
