If a new user is added to config file but NOT at the end of the file, permissions get messed up and I get PermissionError's

[nathanielobrown]

Summary

My analysis so far is that there is an issue with chown setting the wrong permissions for folders if new users are added NOT at the end of the config file.

Context

My config file looks like and is mounted into the pod at /etc/sftp:

user1:asgfafadfasdf:e:::upload,download
user2:asfgdasdfasdfsd:e:::upload,download
user3:asdfasdfsdfdsf:e:::upload,download

I have a persistent storage volume mounted to /home

Periodically I add new users and restart the SFTP container. I've found that if a new user is added not at the end of the file, than existing folders for users that come after the new user in the config file will have their permissions changed to be owned by the previous user in the config file. I think removal of connections might also cause the same issue, and there's a chance I have whether it is the previous or next user that get's set of the owner.

I've mostly avoided having the order of the file changed (new users always go at the end, try not to remove users), but due to an occasional pattern of user deactivation and reactivation I really need to come up with a better solution.

Analysis

• chown is run by create-sftp-user script ([source](https://github.com/atmoz/sftp/blob/master/files/create-sftp-user)) which operates on a single row of the config file
• I think the issue is in uid="$(id -u "$user")" which then gets used for chown -R "$uid:users" "$dirPath" (dirPath is created with dirPath="/home/$user/$dirPath")

Potential Solutions

• Maybe chown -R "$uid:users" "$dirPath" could be changed to chown -R "$user" "$dirPath"?
  • Someone who knows better than me should comment on whether this would have unintended consequences!
• Maybe there's something I can do to avoid this issue? I think this is a clear bug but would love a mitigation if anyone has one

[thalesmaoa]

Just to add to the topic.
That has similarity with the problem I'm facing.

I was deploying a wordpress and opened sftp for the TI guy. He was complaining about permissions and I found a interesting behaviour.

Here is the docker-compose file

services:
  sftp:
    image: jmcombs/sftp
    container_name: sftp-server
    volumes:
      - /home/thales/docker/wordpress/www:/home/old_wp
      - /home/thales/docker/wp-docker/html:/home/new_wp
    ports:
      - "2222:22"
    command: [old_wp:old_wp:33,new_wp:new_wp:33]

$ ll -n | grep html
drwxr-xr-x 2   33   33 4096 Jan 10 16:02 html/

After starting the container, html ownership is changed to root:root.

$ ll -n | grep html
drwxr-xr-x 2  root root 4096 Jan 10 16:02 html/

If I revert:

$ sudo chown 33:33 html -R

I get

Accepted password for new_wp from 201.80.28.130 port 56745 ssh2
bad ownership or modes for chroot directory "/home/new_wp"
Received signal 15; terminating.

It drops my connection.