scp not tolerant of extraneous shell messages

[Nicolas.Williams at ubsw.com]

On Tue, 2 Jul 2002, Ben Lindstrom wrote:
> On Tue, 2 Jul 2002 Nicolas.Williams at ubsw.com wrote:
> > I spoke of sub-systems generally - sftp may or may not care
> > about umask settings - other sub-systems might in fact care.
> 
> Which would be a flaw in the subsystem application that was written.
> Unless you know for a fact that subsystem will *NEVER* be 
> implemented on a
> non-UNIX based platform.

By using the shell to launch the sub-system you win
platform independence with respect to setting of umask.
Q.E.D.

As for other sub-systems and their use of permissions: there is
nothing wrong with assuming that ACLs/umasks/whatever are set
correctly and that new files created by a sub-system will
therefore inherit the correct permissions. To do otherwise would
defeat useful mechanisms for setting default permissions
(possibly in context-sensitive ways, as with ACLs, which can be
inherited from a file's containing directory)

> In reality, file permissions should be set by the application 
> or by the
> end-user that is connecting.  To do so otherwise is non-portable.

The setting of file permissions itself varies from platform to
platform.

Some apps should indeed set permissions directly (e.g., package
managers) and some should not (because having file perms set by
directory ACLs or process umasks can be a very useful thing)
and some should give the user the option (I believe this ought
to include file transfer applications [and protocols]).

> After saying that.  I still agree that the user's shell needs 
> to be ran.
> =) Because it's the correct way for UNIX to handle things.

Good. :)
 
Nico
-- 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.