[scponly] Integrating a file sharing system (long)

[Kaleb Pederson]

On Friday 25 August 2006 3:50 am, Sven Ingebrigt Ulland wrote:
> On Thu, Aug 24, 2006 at 09:28:23PM -0700, Kaleb Pederson wrote:
[snip]

> Ah, I was maybe a bit unclear on that. The system uses only one local
> LDAP database to fetch info from

I understood that at one point... and then lost it somewhere.

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

What I would suggest follows.  Patch scponly so that before it drops privs it 
executes a program or script which performs the rest of the processing.  This 
would put the least impact on scponly and allow for easier customization 
later.  You could wait for the forked process to return if need be.  This 
change could be written in about 6 lines of C code. (NOTE: not written as a 
formal patch, but informal to allow you to execute a single arbitrary 
program, and possible wait for it's return.)

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

I would definitely let the script or program executed by scponly handle 
everything except what scponly is intended for.  I would probably have 
scponly pass a single parameter, the username of the person logging in.  The 
script could then look up the rest of the information as it exists in ldap, 
which would make it really easy to change.

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

Both of the above happen depending on how you define group membership in LDAP.  
The latter is the more formal way, with each group containing a list of dn's 
(eg. the fully qualified path name to the user).  Either can be made to work.

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

Exactly.  And I would have the calling script do this.  Note that (1) would be 
handled by pam_ldap before it ever got to scponly.  You might be able to even 
make the call to execute the program after permissions were dropped (assuming 
we could get hard-linking to work), as you wouldn't need root permissions to 
bind.... Just a possibility.

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

I was thinking about hard-linking the project directory into the users home 
hierarchy, not the files specifically.  Thus, once the user descended into 
the project hierarchy, he would have access to the files.  My concern related 
to security is that if there were a hardlink there might be a way to break 
out of the chroot.  I'm just not sure on that detail.

--Kaleb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ccs.neu.edu/pipermail/scponly/attachments/20060826/2acc141a/attachment.bin