[Analysis] UID is fine, but different GID is used on uploaded files

[reinerwill]

Hi,

When I upload files in the standard configuration, the files being set to uid/gid 1000:1001. I changed the json config to use 444:444 instead, but when I upload files they get 444:1001. Why is the gid ignored, please?

My config:

cat /etc/sftp/sftpamsnor.json
{
    "Global": {
        "Chroot": {
            "Directory": "%h",
            "StartPath": "upload"
        },
        "Directories": ["upload"]
    },
    "Users": [
        {
            "Username": "amsnor",
            "Password": "xxyyzz",
            "UID": "444",
            "GID": "444"
        }
    ]
}

cat /etc/init.d/sftpamsnor.sh
#!/bin/bash
#
# Start docker container for amsnor sftp upload
#

docker run \
 -p 10328:22 \
 -d \
 --name sftpamsnor \
 -v /etc/sftp/sftpamsnor.json:/app/config/sftp.json:ro \
 -v /data/nfs/assets/amsnor:/home/amsnor/upload/assets \
 -v /data/nfs/compliance/amsnor:/home/amsnor/upload/compliance \
 -v /data/nfs/schedules/amsnor:/home/amsnor/upload/schedules \
 emberstack/sftp

[reinerwill]

Just an idea: the linux command useradd has two options for gid, one setting the primary group and another for setting supplementary groups. Are there different options in the json settings for these two types of groups?

Usage: useradd [options] LOGIN
       useradd -D
       useradd -D [options]

Options:
...
  -g, --gid GROUP               name or ID of the primary group of the new
                                account
  -G, --groups GROUPS           list of supplementary groups of the new
                                account
...

I'm thinking about this after reviewing the logs:

2021-12-10 09:38:58.332 [INF] (ES.SFTP.Host.Security.UserManagementService) Processing user 'amsnor'
2021-12-10 09:38:58.336 [DBG] (ES.SFTP.Host.Security.UserManagementService) Creating user 'amsnor'
2021-12-10 09:38:58.427 [DBG] (ES.SFTP.Host.Security.UserManagementService) Adding user 'amsnor' to 'sftp-user-inventory'
2021-12-10 09:38:58.446 [DBG] (ES.SFTP.Host.Security.UserManagementService) Updating the password for user 'amsnor'
2021-12-10 09:38:58.600 [DBG] (ES.SFTP.Host.Security.UserManagementService) Updating the UID for user 'amsnor'
2021-12-10 09:38:58.648 [DBG] (ES.SFTP.Host.Security.UserManagementService) Creating group 'sftp-gid-444' with GID '444'
2021-12-10 09:38:58.663 [DBG] (ES.SFTP.Host.Security.UserManagementService) Adding user 'amsnor' to 'sftp-gid-444'

It says updating UID, but adding at the group message.

[winromulus]

Hi @reinerwill
The GID is added to the user (basically a group is generated if it does not exist).
All directories created for a user are chown-ed to username:SftpUserInventoryGroup (the SftpUserInventoryGroup is an internal one containing all users generated by the host process from configuration).
Changing that might break chroot.
I think the permission list might need to be augmented with ACL using hooks in your case (not sure, just thinking outloud). Have a look at the samples for hooks.

[MrDonkey07]

I am having the same issue as described by @reinerwill. When a user creates a file inside the container it is owned by a different GID than specified in the config.

This occurs because a new primary group for the user in the container is created when the useradd call is made. Files created by that user are automatically owned by the user's primary group, regardless of if the user belongs to other groups.

I put together PR #89 that will address this issue and assign primary groups as specified in the config file.

[MrDonkey07]

One additional possible concern would be what happens with host permissions when a GID in the container matches a different GID on the host. I will create a separate issue for that.

[winromulus]

@MrDonkey07 - I'm evaluating your PR right now to make sure that everything is still okay (bit of ramp-up to do on my end).
Regarding the host permissions, as mentioned in #90 , I don't think that's something we can solve.

[reinerwill]

Hi @reinerwill The GID is added to the user (basically a group is generated if it does not exist). All directories created for a user are chown-ed to username:SftpUserInventoryGroup (the SftpUserInventoryGroup is an internal one containing all users generated by the host process from configuration). Changing that might break chroot. I think the permission list might need to be augmented with ACL using hooks in your case (not sure, just thinking outloud). Have a look at the samples for hooks.

When not specifying UID and GID in the json config the user will use 1000:1001. When I add UID and GID to the config, only UID is used correctly. This looks still like a bug to me. I set these to 444:444 and file are getting 444:1001.

[EVOTk]

When not specifying UID and GID in the json config the user will use 1000:1001. When I add UID and GID to the config, only UID is used correctly. This looks still like a bug to me. I set these to 444:444 and file are getting 444:1001.

I have the same behavior.

[fliot]

Me too, same behavior,
Files are written with 444:1001 ownership.

[stale]

Automatically marked as stale due to no recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Automatically closed stale item.