Re: [SAGE] incoming file transfers, and collaborative environmentsin general

[Doug Hughes <doug@eng.auburn.edu>]

On Tue, 4 Jan 2005, Jim Dennis wrote:

> On Tue, Jan 04, 2005 at 02:15:01PM -0500, Betsy Schwartz wrote:
> > A specific problem: I've been asked to think about ways to allow "friends
> > of friends" to upload files to our servers. Obviously we don't want to
> > enable anonymous incoming FTP or anything like that  - nor do we want to be
> > creating accounts for these users. I think ideally we'd use our existing
> > authentication system to give a user a "ticket" they could give to the
> > sender. Are there any existing systems that allow something like this?
>
>  I used to use "dark" directories for a small scale approach to this.
>  Basically I'd have certain directories on my FTP site which were
>  not readable to the FTP users.  The were traversable, (x bit was set)
>  but not readable (r bit was cleared).
>
>  Thus someone could cd into any directory there under, if they knew
>  or could guess the name.  However, they couldn't read the name is
>  a listing.
>
>  Obviously the incoming directories were were also not readable (so you
>  could drop files into them but neither see nor read what was already
>  there).
>
>  Disadvantages:
>    * *some* users of GUI FTP clients couldn't cope with these
>    * obvioulsy these hidden directory names, like any sort of shared
>      "password" will leak out, end up in Google caches, etc.  (Therefore
> 	 they should be relatively short lived).
>    * vulnerable to name guessing attacks (like any passwords, but
>      unmitigated by exponential back off delays --- though I suppose a
> 	 hacked FTP daemon could support them)
>    * confusing to most users and some admins; hard to explain.
>
>  Advantages:
>    * No special software required on the client or server side
>    * Relatively transparent to most software and users; support
>      mostly amounts to: "connect to $SERVER and cd to $DIRECTORY"
>    * Relatively low maintenance overhead.  It's wise to create 'at'
>      jobs to chmod 000 each of these dirs after an expiration date.
> 	 Whatever script creates the directory should schedule the at job
> 	 immediately.
>    * You can create custom scripts for all authorized users to create
>      and maintain these directories.  Have the "expiration" at jobs
> 	 send them e-mail, too!
>
>  Caveats:
>    * This should not be construed as a secure way to distribute valuable
>      files.
>    * Think of this as a way to limit the abuse to your bandwidth that
>      server disk space and other resources would be caused by public
> 	 "incoming" and other directories.
>    * Valuable data should be encrypted and signed (GPG or better).
>
> > In general"  what are interesting sites or books to learn about
> > collaborative environments? I know about  WebDav and wikis, but beyond that
> > I'm finding a bewildering variety of information (and much hype). I need to
> > become a Subject Matter Expert in this and I'm not quite sure where to
> > start. Our users are architects, landscape architects, urban planners, and
> > other sorts of designers, with a few random Pure Design and Industrial
> > Design and other such folks in the mix.  In general they are interested in
> > collaborating on web sites and exchanging Very Large image files, not so
> > much in fancy interactive whiteboards etc (although it would be good to
> > learn more about all that too...)
>
> > thanks for any pointers
> > Betsy
>
>  I'll be interested in a summary of your conclusions after you've
>  read all the responses to this thread, searched around and evaluated
>  a few of your options.
>
>

I've used a twist on this where you set the ftp server (usually wietse's,
and usually with the -u flag) to set it so that the owner (ftp) could
not read the file once it was put.

Thus, external people could drop of files to internal people, but
no other external people could then subsequently fetch the files.
This avoids the 'warez' problem because they quickly realize that
while they can store stuff there, it doesn't do them any good
because they can't fetch it afterwards.

Of course, this may not suit the requirements at all, but I though
I'd offer it just in case.

	Doug