9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: rsc@plan9.bell-labs.com rsc@plan9.bell-labs.com
Subject: [9fans] Plan9 permissions
Date: Mon, 15 Sep 1997 13:59:43 -0400	[thread overview]
Message-ID: <19970915175943.vloZVwp08KAkJrXLummPPiLmSv7om4Y_UAkE2fTiKVs@z> (raw)


	gdb wrote:

	Take for example the incoming directory for anonymous ftp,
	/usr/none/incoming.

There is a way to handle incoming directories for
anon ftp working within the current permissions scheme, and it
is (tersely) illustrated on the CD.  (Basically, we want to be able
to drop files off in /incoming but don't want the outside world to be
able to read them).

You can create a directory in incoming for each user,
and set the permissions appropriately:

	d-rwxrwx-wx rsc rsc /usr/none/incoming/rsc

Or you can just create a directory in incoming named for each
user (but with any permissions, ownership you want) and bind
the directory /usr/$user/incoming onto it, as was done in 
/lib/namespace.ftp on the CD:

	bind -c /usr/andrew/incoming /usr/none/incoming/andrew

This has a few benefits.  The first is that each user has h^(is er)
own incoming directory and thus the namespace collisions go 
down tremendously (most users know when they are expecting files,
especially files named "foo" or "bar").  

Another advantage is that each user can turn on or off,
quite easily, whether or not they
are expecting files.  Just "chmod o-wx incoming".  By
having this on only when expecting files, you reduce the chance of
someone maliciously filling your disk with garbage.
If you were really paranoid, you could "chmod -r /usr/none/incoming"
and then people would have to know which directory to be in
to drop off files.

Third, if you don't want the world seeing whatever file
is being dropped off, you might not (at least on a large server
installation) want other users of the system seeing it either.
This takes care of that as well.

Fourth, if you want to leave a file for someone else, then you
can simply create one in your incoming directory and chmod it
"o+r" and then if they know the name, they can still read it.

You've got all the functionality of the traditional ftp
/incoming directories as well as easy user control of personal
incoming directories.

Russ

ps. ignore my from address; i speak with less authority
(and perhaps common sense) than anyone else on this list.




             reply	other threads:[~1997-09-15 17:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-09-15 17:59 rsc [this message]
  -- strict thread matches above, loose matches on Subject: below --
1997-09-15 19:33 G.David
1997-09-15 15:18 G.David
1997-09-15 15:15 Lucio
1997-09-15 14:38 G.David
1997-09-15 14:26 rsc
1997-09-15 14:22 Lucio
1997-09-15 13:52 rsc
1997-09-15 13:28 G.David

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19970915175943.vloZVwp08KAkJrXLummPPiLmSv7om4Y_UAkE2fTiKVs@z \
    --to=rsc@plan9.bell-labs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).