Subject: filexfer, create umask

From: [email-masked] (Niels M�ller)
Date: 11 Jan 2001 15:04:50 +0100

When creating a file (using SSH_FXP_OPEN, with SSH_FXF_CREAT), I
understand that the umask (however that is configured, probably in the
/etc/profile if the ftp service is started by exec:ing /bin/sh -c
sftp-subsystem) would be applied if the user doesn't specify any
permission bits; this is a reasonable interpretation of "Default
values will be used for those attributes that are not specified."

But what if the permission bits *are* specified by the client? Should
they be filtered through the user's umask, or should the server make
sure they are really used as is (by clearing its umask)?

/Niels

---

From: Sami Lehtinen <[email-masked]>
Date: Fri, 12 Jan 2001 01:24:03 +0200

Niels Möller, on January 11. 2001, wrote:
  : When creating a file (using SSH_FXP_OPEN, with SSH_FXF_CREAT), I
  : understand that the umask (however that is configured, probably in the
  : /etc/profile if the ftp service is started by exec:ing /bin/sh -c
  : sftp-subsystem) would be applied if the user doesn't specify any
  : permission bits; this is a reasonable interpretation of "Default
  : values will be used for those attributes that are not specified."
  : 
  : But what if the permission bits *are* specified by the client? Should
  : they be filtered through the user's umask, or should the server make
  : sure they are really used as is (by clearing its umask)?

I think we want to use the *nix philosophy here, and use it filtered
with umask.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: Tatu Ylonen <[email-masked]>
Date: Fri, 12 Jan 2001 18:38:37 +0200 (EET)

> I think we want to use the *nix philosophy here, and use it filtered

There may be practical implementation problems with this.  The umask is
typically set by the user's .cshrc files (or equivalent).  The only way to
get umask set is to run the user's login shell, have it evaluate all
config files, and then run the file transfer code as a separate module.

There are several reasons why I think this may be a bad idea:

  - some implementations may want to include sftp server in the same
    process that implements the SSH protocol

  - one could very reasonably want to create accounts that allow sftp
    transfers to/from certain subdirectories but nothing else (e.g.,
    allowing product managers to information related to their own products
    on a web site).  Enforcing such policies becomes tricky if the daemon
    reads config files.

  - umask makes it more difficult to implement e.g. "scp -p" (preserve
    modes) option.

  - I remember at least one account that I've had where the initial .cshrc
    did not set umask but .login did.  .login is not executed when you
    just execute an external program through the login shell.

  - suppose the protocol was ever used as a file sharing protocol.  What
    would happen if umask was implemented both by the client and by the
    server?

None of these is a critical issue, but overall I think it would be better
to not have the server do umask processing.  Instead, I would add a note
that if the client does not support unix-like file modes, it should not
send any, and if the server does not receive modes for open/create, it
should default to 644.

Thus, my vote would be that server should clear umask, have a reasonable
default, and client should send the modes if it wishes a particular mode.
I don't have a very strong opinion though.

    Tatu

---

From: [email-masked] (Niels M�ller)
Date: 15 Jan 2001 01:01:24 +0100

> default, and client should send the modes if it wishes a particular mode.

I agree. If the client goes to the trouble of providing the permission
bits, it seems right to use them as they are, without filtering. (One
might want the *client* to do umask filtering, though).

/Niels