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

[Dan Knapp]

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