Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
reinerwill opened this issue Dec 10, 2021 · 10 comments
Closed
Labels
question Further information is requested stale

Comments

@reinerwill
Copy link

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
Copy link
Author

reinerwill commented Dec 10, 2021

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
Copy link
Contributor

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.

@winromulus winromulus added the question Further information is requested label Dec 19, 2021
@winromulus winromulus changed the title UID is fine, but wrong GID is used [Analysis] UID is fine, but different GID is used on uploaded files Dec 19, 2021
@MrDonkey07
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Author

reinerwill commented Dec 27, 2021

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
Copy link

EVOTk commented Jan 17, 2022

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
Copy link

fliot commented Feb 9, 2022

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

@stale
Copy link

stale bot commented Apr 16, 2022

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

@stale stale bot added the stale label Apr 16, 2022
@stale
Copy link

stale bot commented Apr 28, 2022

Automatically closed stale item.

@stale stale bot closed this as completed Apr 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested stale
Development

No branches or pull requests

5 participants