I don't quite follow all you are trying to do so perhaps
this doesn't apply.
For basic file sharing I use the first part of Vincent
Danens article here
http://blogs.techrepublic.com.com/opensource/?p=229
and set up a separate user for each group that needs to
share files.
Access with Filezilla on Win, OSX and LInux or use
sftp://user@host in konqueror.
Each group has a common username and password and can
read/write/blow-away files in their shared directory without
affecting other groups.
They have no shell access, I turn off ssh root login and use
a separate account to ssh in for admin.

Regards,
Bob


----- Original Message Follows -----
From: Andrew Berg <bahamutzero8825 at gmail.com>
To: TCLUG Mailing List <tclug-list at mn-linux.org>
Subject: Re: [tclug-list] Need a simple web interface to
passwd
Date: Tue, 13 Apr 2010 08:03:25 -0500

> On 4/13/2010 7:12 AM, gm5729 wrote:
> > You can chroot jail users who have shell access you know
> > too so no one can creep back up the tree. Permissions,
> >   Permissions, Permissions.... 
> Perhaps I could chroot ssh users to an empty directory,
> though somehow I think they may still be able to shoot
> themselves in the foot... My main concern with these users
> is that they could accidentally do something bad to the
> shared directory, and not so much that they would even
> have a clue how to mess up the system overall. Also, AFAIK
> , it's impossible to get root access without knowing the
> credentials of someone who has shell access, even if you
> know root's password (assuming of course that root is not
> allowed to log into FTP or SSH, which is the case here).
> > IPTABLES can go great with  port
> > knocking which adds another layer of security.
> Shorewall (a frontend to iptables) seems to be working
> nicely. The policy is a whitelist, letting only the
> handful of us in to access a few select ports. A script
> kiddie would have to hijack one of my users' machines to
> even have a hope of trying to compromise an account. If
> it's possible, I'd like to restrict logins to each
> specific account so that each user couldn't log in as
> another, even though both users are allowed to use the
> > system. LONG LONG
> > Passphrases. If someone wants to ssh into my box. They
> > won't get away with at least a minimum 30 charc
> passphrase or more! Unfortunately, there are easier ways
> for someone to compromise one of my users' accounts than
> brute force. Stupid FTP clients don't protect their site
> > managers... I don't follow
> > you must change them 30 days, but they do need to be
> > changed quickly if a person is pink slipped or
> >   transfers. 
> If someone gets kicked out, their account is gone. I don't
> need to recycle accounts.
> > Couple more ideas. Skype is secure by it's design. Even
> > it's creators can't snoop on a P2P or conference call.
> > Pidgin has OTR and GPG/RSA encryption available. Files
> >   transfers can be done there. 
> We're dealing with very large files shared by multiple
> people who are not going to schedule a meeting to transfer
> > files. If I were "renting" a box I wouldn't
> > entrust any business secrets on it unless you are
> > running GPG, scrypt, or bcrypt.
> I trust the host enough not to go snooping around. Not
> that we keep anything really sensitive on the box anyway.
> > I have issues with Truecrypt and think it too
> > complicated of an encryption application.
> I have TrueCrypt on my laptop and I don't find it terribly
> complicated. There's too much that can go wrong during
> initial set up that can cause a lot of hassle on a box I
> > don't have physical access to, though. My password for
> > my boxen as root are ~charcs or more. My $user passwds
> for my boxen are ~15-20 charcs. I admit I do need a longer
> root password, but if I can't remember a 15-character
> password, I can't trust my users (who are a lot less
> security-conscious than I am) to use a long password /and/
> protect it properly from co-workers and other nosy people.
> A 20-character isn't any stronger than a 5-character one
> if it's on a post-it note stickied to the monitor. A
> brute-force attack is extremely impractical unless an
> attacker can bypass the firewall.
> 
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>