client: Is there any way to create a file on the server with specific permissions?

[toby-allsopp]

It looks like neither Client.Create or Clilent.Open provide a way to specify the file mode (e.g. 0640) when creating a file. I see that I can use Chmod once the file exists, but that leaves a window open where the file is accessible using the default permissions. Is there some way around this?

[eikenb]

Currently no. The protocol supports sending file attributes along with the Open packet, but the client implementation doesn't utilize that presently.

I don't see anything preventing it from being added, though it would need to be a new method so as not to break backwards compatibility. CreateWithMode() or some such.

I'd be happy to review PRs for this or we could convert this ticket into a feature request.

[toby-allsopp]

We've postponed the feature I was working on that required this feature, so I won't have time to work on it in the near future. If/when we pick it up again I'd be happy to create a PR but until then it's probably best to mark it as a feature request. Thanks!

[puellanivis]

Hm, we probably should have made https://pkg.go.dev/github.com/pkg/sftp?tab=doc#Client.OpenFile support perm parallel to os.OpenFile. 🤷‍♀ Too late now, though.

But I would recommend expanding Client.OpenFileWithPerm or WithMode instead, or some other way to specify more options that exclusively from the default flags in Client.Create. Or perhaps using Client.CreateWithMode(filename, flag, perm) which does flag |= os.O_CREATE or something?

[Kagami]

I had a similar problem with this package: it creates files with 664 permissions and directories with 775, even though umask is 022.

I found a fix though: replace ForceCommand internal-sftp with ForceCommand internal-sftp -u 022 in /etc/ssh/sshd_config and restart sshd.

[puellanivis]

Where was the umask? On the client? Because the server code runs on a completely different server, and does not automatically respect umask from the client.

[Kagami]

You're right, it turned out that target user had umask 002 (due to USERGROUPS_ENAB yes in /etc/login.defs).

I was confused by sftp executable because it preserves permissions.

[puellanivis]

No problems. There’s a lot to keep track of when using this package.