[scponly] PATCH: support for multiple users with the same uid

[Steve Kehlet]

/bonk why do you always think of these things the moment after  
sending an email...

I guess a solution in that case would be to create a second acl for  
the user on his directories, giving him full access.

Thanks again for the idea.


On Jun 11, 2007, at 10:02 AM, Steve Kehlet wrote:

>> What I usually do to work around the group permissions issue is to  
>> setup a
>> default ACL that gives the daemon full access to the files.  The  
>> ACL lets the
>> daemon change the file, rename it, etc. and makes the users umask  
>> and file
>> permissions irrelevant.  As long as the filesystem in questions  
>> supports file
>> and directory default ACLs, this method works extremely well and  
>> still allows
>> the operating system to enforce permissions.
>
> Ahh, I like the idea, thanks.  I think in my case though, the  
> daemon creates new files, and they'd be created with the wrong  
> ownership and permissions.  Then the users might run into  
> permissions problems, depending on what they tried to do.  Though  
> maybe if they owned the containing directory it wouldn't really  
> matter for uploading/downloading stuff via sftp, not sure...
>
> Steve
>
>
>
> On Jun 6, 2007, at 9:42 PM, Kaleb Pederson wrote:
>
>> On Wednesday 06 June 2007, Steve Kehlet wrote:
>>>> Just
>>>> to make sure I'm understanding this, what you do is put multiple
>>>> lines in
>>>> /etc/passwd which have different usernames but the same uid?
>>>
>>> Yes, exactly.  Multiple passwd entries, each has a different
>>> username, password, home directory, and jail, but they all have the
>>> same uid.  Since their scp/sftp access is jailed, they can only get
>>> to their own stuff.  There's a daemon process, running as that same
>>> uid, that looks for files inside people's jails and does some
>>> processing on them.
>>>
>>> By doing it this way I'm saving the headache of managing group
>>> permissions between that daemon process and each user.  Running a
>>> daemon per user is not an option.  You're not going to win any
>>> sysadmin of the year awards for designing a system that overloads
>>> uids, but... in this case it's solid and it works.
>>
>> What I usually do to work around the group permissions issue is to  
>> setup a
>> default ACL that gives the daemon full access to the files.  The  
>> ACL lets the
>> daemon change the file, rename it, etc. and makes the users umask  
>> and file
>> permissions irrelevant.  As long as the filesystem in questions  
>> supports file
>> and directory default ACLs, this method works extremely well and  
>> still allows
>> the operating system to enforce permissions.
>>
>> This also allows me to use group permissions as needed, but  
>> doesn't require
>> that they be in place.
>>
>> --Kaleb
>