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

[Steve Kehlet]

> 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.

> is how to maintain many source repositories and give different  
> people access
> to each, without setting up separate users.

Hmm, yeah, without knowing more it's hard to weigh in...  But just  
note what I'm doing isn't any less work, I still have to create /etc/ 
passwd entries, home directories, populate a jail structure per user,  
etc.

Good luck!

Steve



On Jun 6, 2007, at 2:50 AM, Dan Knapp wrote:

> I'd actually like to hear more about how you're doing this.  It  
> sounded a little
> over-elaborate at first, but it could be handy for a problem I keep
> having, which
> is how to maintain many source repositories and give different  
> people access
> to each, without setting up separate users.  My conclusion so far  
> has been that
> I'm wrong to want to avoid using separate users because any viable  
> strategy
> would just reinvent them, but anyway, your thing seems worth  
> considering.  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?   
> Interesting...
>
> On 6/5/07, Steve Kehlet <stevek at webreachinc.com> wrote:
>> Hi Kaleb,
>>
>> Sure thing, it's for a Linux-based appliance I'm creating.  There
>> will be no shell access.  Users will scp/sftp stuff up into
>> individual jailed areas, then a daemon process will read/write those
>> files, possibly move them around (say from a user's "inbox" subfolder
>> to "processed"), etc.  The jails keep users from mucking around with
>> each other's stuff, and using the same uid for all the users and the
>> daemon process saves a ton of headaches with permissions, umasks,  
>> etc.
>>
>> Before this, I did take a long look at doing it "the right way", with
>> separate uids, managing groups and appropriate group perms on all
>> directories, then building a custom openssh with various available
>> patches for chroot, restrictions on chmod so the users couldn't break
>> any of the carefully set up permissions, running with a custom umask
>> to enforce correct perms on new files/directories, adjusting the
>> daemon's umask (possibly requiring modifying source code/startup
>> files, developed by another team), etc, but after a while it seemed
>> rather fragile and in fact pointless since there would never be shell
>> access anyway.  Add that it's an appliance running outside of my
>> control, and I wouldn't be able to log in and fix something if it
>> broke.  Note: it has been deemed acceptable that the same (fairly big
>> and expensive, java-based) daemon process handle all users' data.
>>
>> That's the gist of it.  scp/sftp isn't the only upload mechanism, but
>> it's a required one, and the only one with file browsing abilities,
>> which I need jails for.
>>
>>> so I'm curious if it's something I would consider a reasonable use
>>> case.
>>
>> I'd understand if you'd consider my case unique, and I can maintain
>> my own patch no problem.  But I think my patch addresses a not-so-
>> unreasonable, albeit uncommon, case where scponly can grant access
>> outside a user's jail, in a way that only makes it safer.
>>
>> Thanks!
>>
>> Steve
>>
>>
>>
>>
>>
>> On Jun 4, 2007, at 10:08 PM, Kaleb Pederson wrote:
>>
>>> Steve,
>>>
>>> The patch itself seems fine, but I would like to know more about
>>> why you need
>>> to have multiple users with the same uid?  Obviously, this prevents
>>> the
>>> operating system from enforcing permissions based on uid, which
>>> doesn't seem
>>> like a good idea to me -- so I'm curious if it's something I would
>>> consider a
>>> reasonable use case.
>>>
>>> Thanks.
>>>
>>> --Kaleb
>>>
>>> On Monday 04 June 2007, Steve Kehlet wrote:
>>>> I acknowledge sharing uids in general is not considered a best
>>>> practice, but it's a nice solution for what I'm doing (I'll  
>>>> spare you
>>>> the details).  As far as I can tell, the above change seems safe,
>>>> provides arguably more correct/expected behavior, and may be useful
>>>> for others too.  But, I submit it here for review, so please  
>>>> post if
>>>> you see something I haven't or if you otherwise disagree :-).
>>>> Hopefully you'll like the patch and merge it in.  Many thanks, I
>>>> think scponly is a very handy package.
>>
>>
>> _______________________________________________
>> scponly mailing list
>> scponly at lists.ccs.neu.edu
>> https://lists.ccs.neu.edu/bin/listinfo/scponly
>>
>
>
> -- 
> Dan Knapp
>
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly