[scponly] Integrating a file sharing system (long)

Fri Aug 25 06:50:21 EDT 2006

On Thu, Aug 24, 2006 at 09:28:23PM -0700, Kaleb Pederson wrote:
> First off, everything seems reasonable ;)
> 
> IIRC, pam_ldap only supports one ldap.  I tried using pam_stack once to get 
> multiple ldaps to work together, but it never worked and a number of searches 
> seem to indicate that it wasn't possible.  If you could setup your system to 
> hit a single ldap and then setup your scripts to populate that ldap you would 
> be in pretty good shape in terms of authentication.

Ah, I was maybe a bit unclear on that. The system uses only one local
LDAP database to fetch info from. Existing company users are
synchronized to this local db from another LDAP database. External
users are created directly in the local db.

> Now, regarding mounting and other things, it seems like you should be able to 
> get away with a really simple patch to scponly.  I would probably modify it 
> so that it executed a single program/script (possibly setuid root or before 
> dropping permissions).  That script could then mount --bind the necessary 
> directories and do any other customization that needed to happen.

That would be great! I was thinking about doing it myself.. though I'm
not a C guru. An extension to scponly like the one you mention should
be able to deal with variables such as $username and $groups.. but
having it deal with a variable list/array would probably make it too
complex?

Another thing, maybe more crucial: When a user logs in, some system
(could be scponly or maybe pam-ldap) must either
a) get a list of projects that user is member of, and loop through
   that list and mount, or
b) call another program to do that.
What would you suggest is the best approach?

Now, I don't know if in LDAP that
a) user entries refer to what groups the user is a member of, or
b) group entries refer to a list of members of that group.

Either way, the procedure could be something like
1) authenticate user by verifying username and password.
2) call user's shell (scponly).
3) before dropping privs:
    a) fetch the list of projects/groups the user is member of.
    b) bind/link the project folders.
4) drop privs and run session.
5) possibly unbind/unlink when terminating session.

> Unmounting (unbinding) the filesystem would probably be problematic.  You 
> wouldn't be able to guarantee that scponly could cleanly unmount the project 
> directories, although cron might be able to help you there.  You might be 
> able to use hard links instead, but I'm not sure if there are any security 
> concerns that you would need to take into account were you to do that.  At 
> least with hard links it would be pretty easy to write a script that verifies 
> and removes hard links that should not exist at the time.

Hardlinking is a good idea, I'll look into it. My primary concern is
concurrency, if two users modify a file at the same time, or one user
deletes a file .. then it would only lose one link, and not be
removed.. hmm..

> Hopefully that helps.

Yes, thanks! It's great to get some input.

Sven

> On Thursday 24 August 2006 12:44 pm, Sven Ulland wrote:
> > Hi. I've started a project for a standalone file sharing system where
> > people can use both sftp/scp and a web interface (WebDAV or something)
> > for uploading and downloading files. This is to be used in a
> > development environment where people can share builds and other files.
> >
> > The thing is, I want the entire system to resemble the design of
> > mailman and similar systems: The admin can create "projects" (mailing
> > lists in mailman) and add individual users (mail addresses in mailman)
> > to the projects.
> >
> > Additionally, It would be truly sweet if each project could be
> > assigned an owner (list owner in mailman) that can add or remove
> > project members without bothering the admin for every little change.
> >
> > The user base is kept in a local LDAP database, and the users are a
> > mixture of both internal (fetched from the main company LDAP database)
> > and external (added to the local LDAP database as needed) participants.
> >
> > An example:
> > * Admin creates a project called "foobar-sdk".
> > * Admin assigns the user "joeblow" as project owner. (optional)
> > * joeblow or admin can use some sort of script or interface to add
> >   users to the project.
> >    - If the user is internal, fetch username and password from the
> >      main company LDAP database and store it in a local LDAP database.
> >    - If the user is external, add the user to the local LDAP database
> >      and set a password.
> >    - Set the users' homedirs to /opt/users/<user>//files (chroot to
> >      user homedir with scponly).
> >    - Add them to the appropriate posix groups (projects).
> > * Now the users can log in and upload/download files in any project
> >   they are members of.
> >
> > This presents some challenges in regards to scp/sftp with scponly:
> > * A user "jane" can be a member of several projects, for example
> >   "foobar-sdk" and "parrot-db". A though-of solution to this is to use
> >   something like this upon login with sftp/scp/web:
> >     "mount --bind /opt/projects/foobar-sdk
> > /opt/users/jane/files/foobar-sdk" "mount --bind /opt/projects/parrot-db
> > /opt/users/jane/files/parrot-sdk" .. so that jane can see all her projects
> > (and her own files) when logging in with scp/sftp.
> > * Also, each project folder (/opt/projects/*) would have the setgid
> >   bit set, so that the group membership is maintained for uploaded
> >   files.
> >
> > This must surely call for code modification in scponly or the pam ldap
> > modules? What I'm thinking of doing is:
> > - In the LDAP database, each user can have a list of groups he/she is
> >   a member of (groups would here be projects, really).
> > - When the user logs in, scponly/pamldap fetches the list of groups
> >   and mounts all the project directories in the user's own homedir
> >   using "mount --bind".
> > - umount the project folders when logging out, or perhaps using a
> >   cronjob if it's hard to tell whether a user has logged out or not.
> >
> > Maybe I have to allow sudo access to the "mount" command for the ssh
> > user?
> >
> > (On a sidenote, I also plan to have an automated revision system for
> > all files: Using inotify (to see when directory contents change), I'll
> > run rsync to a backup directory so that the user always can go back to
> > previous versions of the files.)
> >
> > So, any comments or suggestions on where to start or what to do?
> >
> > regards,
> > Sven U
> >
> > _______________________________________________
> > scponly mailing list
> > scponly at lists.ccs.neu.edu
> > https://lists.ccs.neu.edu/bin/listinfo/scponly

> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly