[9fans] permission bit of /mail/box

[9fans] permission bit of /mail/box

[Kenji Arisawa]

Hello,

I can't create mail box by
mail -c

Permission bit of /mail/box of my system is
term% ls -l /mail
d-rwxrwxr-x M 8 upas    upas 0 Jun  6  2002 /mail/box
d-rwxrwxrwx M 8 upas    upas 0 May  2  2002 /mail/faxoutqueue
d-rwxrwxrwx M 8 upas    upas 0 May  2  2002 /mail/faxqueue
d-r-xr-xr-x M 8 upas    upas 0 May  2  2002 /mail/fs
d-rwxrwxr-x M 8 upas    upas 0 Jun  7 22:51 /mail/lib
d-rwxrwxrwx M 8 upas    upas 0 May 17  2002 /mail/queue
d-rwxrwxr-x M 8 arisawa upas 0 May 17  2002 /mail/ratify
d-rwxrwxrwx M 8 upas    upas 0 Nov 17  2002 /mail/tmp

The bit came from plan9.db
term% grep mail plan9.db
...
mail - 20000000775 upas upas 1019918807 0
mail/box - 20000000775 upas upas 1019918807 0
mail/box/glenda - 20000000775 glenda glenda 1019918807 0
...

How a user can create mail box under d-rwxrwxr-x ?
I suspect the mode bit must be d-rwxrwxrwx


Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

We protect /mail/box 777.  It is a hole, i.e., someone can remove your
mail directory should it ever be empty, though that's not ever supposed to be
the case.  Also, they can rename your mail box though they can't remove it and
replace it with a new one.  I should think of something better.

[-- Attachment #2: Type: message/rfc822, Size: 2800 bytes --]

From: Kenji Arisawa <arisawa@ar.aichi-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: [9fans] permission bit of /mail/box
Date: Sat, 20 Sep 2003 19:18:58 +0900
Message-ID: <D921504E-EB53-11D7-A8A3-000393A941BC@ar.aichi-u.ac.jp>

Hello,

I can't create mail box by
mail -c

Permission bit of /mail/box of my system is
term% ls -l /mail
d-rwxrwxr-x M 8 upas    upas 0 Jun  6  2002 /mail/box
d-rwxrwxrwx M 8 upas    upas 0 May  2  2002 /mail/faxoutqueue
d-rwxrwxrwx M 8 upas    upas 0 May  2  2002 /mail/faxqueue
d-r-xr-xr-x M 8 upas    upas 0 May  2  2002 /mail/fs
d-rwxrwxr-x M 8 upas    upas 0 Jun  7 22:51 /mail/lib
d-rwxrwxrwx M 8 upas    upas 0 May 17  2002 /mail/queue
d-rwxrwxr-x M 8 arisawa upas 0 May 17  2002 /mail/ratify
d-rwxrwxrwx M 8 upas    upas 0 Nov 17  2002 /mail/tmp

The bit came from plan9.db
term% grep mail plan9.db
...
mail - 20000000775 upas upas 1019918807 0
mail/box - 20000000775 upas upas 1019918807 0
mail/box/glenda - 20000000775 glenda glenda 1019918807 0
...

How a user can create mail box under d-rwxrwxr-x ?
I suspect the mode bit must be d-rwxrwxrwx


Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[mirtchov]

> I can't create mail box by
> mail -c

this is a problem that needs to be addressed in Plan 9.  currently you
have two solutions:

	- chmod 777 /mail/box and let the user create their mailbox
	when they run /sys/lib/newuser

	- add your administrator user to the upas group

the second one creates a problem because with fossil you won't be able
to chmod -u to the user you've just created, unless you boot in allow
mode (open AW)

the first solution is the one i currently use on my box, but it
creates an even bigger problem -- i _must_ create the mail box as soon
as i add the user, otherwise anybody can create a pipeto file that
serves as a spam bouncer!

so currently to add a new user i need to:

	- create the user in fossil

	- add the user's password

	- create the user's secstore password

	- login as the user and run /sys/lib/newuser which creates the
	mailbox (i used to wstat /mail/box to 777 on fossil's console
	just for this part, but gave up and left it like that)

it's a bit of an overkill, isn't it? :)

andrey

Re: [9fans] permission bit of /mail/box

[Russ Cox]

you could fsys main create /mail/box/andrey andrey andrey d775

Re: [9fans] permission bit of /mail/box

[mirtchov]

> you could fsys main create /mail/box/andrey andrey andrey d775

hadn't thought of that...  presumably it needs to be:

: create /mail/box/andrey andrey upas d775

right?

then mail -c complains that it can't chmod 722 /mail/box/andrey/mbox,
even though i can do it by hand.  strange.

Re: [9fans] permission bit of /mail/box

[mirtchov]

make that:

	> : create /active/mail/box/andrey andrey upas d775

Re: [9fans] permission bit of /mail/box

[mirtchov]

> then mail -c complains that it can't chmod 722 /mail/box/andrey/mbox,

group: upas; mode: 720... that should be the right one, no?

Re: [9fans] permission bit of /mail/box

[Russ Cox]

> group: upas; mode: 720... that should be the right one, no?

the group is not relevant.  nothing runs in group upas.
it is important that the world permissions include x
so that none can open your mailbox to append to it.

Re: [9fans] permission bit of /mail/box

[Dan Cross]

Simply augment newuser on the fileserver console to create /mail/box/whomever
in addition to /usr/whomever.  I have a script I run to create the mailbox
that I run whenever I create a new user.  It echo's the fs(8) commands and I
read them in my C session.  It works reasonably well.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[Kenji Arisawa]

Hello,

Thanks all. Especially sharpshooting
 > they can rename your mail box
by David Presotto was helpful to me.

My conclusion is that permission bits of /mail/box must be 775
and we should create /mail/box/$user using fs console.
I think it is convenient if /mail/box/$user is automatic created
at the time when /usr/$user is created.

And I have a naive question:
In a directory of permission 777, everyone can delete or rename
anyone's file or directory(if empty in case deletion).
Is this necessary or sound property?

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[David Presotto]

There's nothing wrong with having directories anyone can do anything in.

Re: [9fans] permission bit of /mail/box

[Jim Choate]

On Sun, 21 Sep 2003, David Presotto wrote:

> There's nothing wrong with having directories anyone can do anything in.

Depends on context which is the real answer to the question. If you want
anyone to be able to do anything to a particular branch that's cool, use 777.
For most everything else it's a problem so you reduce permissions.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] permission bit of /mail/box

[Dan Cross]

> There's nothing wrong with having directories anyone can do anything in.

With qualifiers.  It depends on who's doing those things.  Or, perhaps
more importantly, how much you trust them.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

Actually, I meant it without qualifiers.  We have 2^9 possible permissions.  One
of them is to allow anyone (that can attach the fs) to do anything.  I can see
when that's a useful thing.  For the /mail/box directory its a bit too much.
Geoff Collyer suggested making the 'a' bit on directories mean that you can't
rename files (ala unix sticky bit?).  I wouldn't mind that for the mail directory.

[-- Attachment #2: Type: message/rfc822, Size: 2300 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] permission bit of /mail/box
Date: Sun, 21 Sep 2003 17:50:40 -0400
Message-ID: <200309212150.h8LLoej01186@augusta.math.psu.edu>

> There's nothing wrong with having directories anyone can do anything in.

With qualifiers.  It depends on who's doing those things.  Or, perhaps
more importantly, how much you trust them.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[Dan Cross]

Dave wrote:
> There's nothing wrong with having directories anyone can do anything in.

And then I wrote:
> With qualifiers.  It depends on who's doing those things.  Or, perhaps
> more importantly, how much you trust them.

And then David Presotto <presotto@closedmind.org> writes:
> Actually, I meant it without qualifiers.  We have 2^9 possible permissions.
> One of them is to allow anyone (that can attach the fs) to do anything.  I
> can see when that's a useful thing.  For the /mail/box directory its a bit
> too much.  Geoff Collyer suggested making the 'a' bit on directories mean
> that you can't rename files (ala unix sticky bit?).  I wouldn't mind that
> for the mail directory.

Ahh, I think we're talking at cross-purposes.  I see now what you mean,
or at least I think I do: there's nothing wrong with being able to
create directories that anyone can do anything in.

I thought you meant there was nothing wrong with having directories
that anyone can do anything in on any given system.  Clearly, there are
some systems where such directories would not be desired, even though
the possibility exists to create them.

	- Dan C.

(As an aside, thinking about this lead to a nice mental diversion on
pondinger the ambiguities inherent in the English language, and how much
we lose when we communicate in such a way that body langage, tone of
voice, etc disappear.)

Re: [9fans] permission bit of /mail/box

[Kenji Arisawa]

What I don't understand is the needs for the directory to allow anyone
to do anything.
I am afraid that the existence of such a directory is something like a
trap door.

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

Then don't use it.  We have a very open environment at the labs.  Lots
of non-critical stuff is in directories or files that anyone can muck with.
All systems stuff isn't.  There has to be an ability to create `trust everyone'
files and directories in such an environment.  If you want to hack your
file server to not allow it, that's why the source is open.

If you are arguing that its too easy to leak things if you leave anything
writable except by small interest groups, then you end up spending a lot
of time changing group membership.  Eventually, every group ends up
being way too inclusive.

You are right that, lacking proper protection modes, the catch all can
be too easily used in inappropriate ways (like for /mail/box).  I believe
that chopping off everyones hands to avoid anyone stealing is perhaps
not the best solution.  I think the boyd/geoff/rminnich/alii solution
to make the 'a' bit meaningful in directories is a good one.  The
trick is making it intuitive also so that people are less likely
to make mistakes.

[-- Attachment #2: Type: message/rfc822, Size: 2173 bytes --]

From: Kenji Arisawa <arisawa@ar.aichi-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] permission bit of /mail/box
Date: Mon, 22 Sep 2003 11:12:13 +0900
Message-ID: <2E2DA000-ECA2-11D7-BC2F-000393A941BC@ar.aichi-u.ac.jp>

What I don't understand is the needs for the directory to allow anyone
to do anything.
I am afraid that the existence of such a directory is something like a
trap door.

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[Kenji Arisawa]

David Presotto:
> Then don't use it.  We have a very open environment at the labs.  Lots
> of non-critical stuff is in directories or files that anyone can muck
> with.
> All systems stuff isn't.  ....

Thanks David.
I complain only to the property:
Anyone can remove or rename other person's file or directory.

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[matt]

> ... Google already has archives going back years; ...

unless you want to see the attachments

Re: [9fans] permission bit of /mail/box

[boyd, rounin]

> Am I thinkng wrong?

yes.

save _everything_.  as it has been pointed out before various financial
institutions are required by law to keep records for n years.

anyway, disk is cheap.  the old fileserver only copied the tree, with
pointers to blocks, so an un-modified block would have one copy,
but with multiple pointers.

as for venti/fossil i can't say -- there's only so many thing a rounin can do.

Re: [9fans] permission bit of /mail/box

[boyd, rounin]

> And use up a lot of memory....  Actually, everyone would use up a lot
> of memory.  Ick.

something that would become altavista used this method.

Re: [9fans] permission bit of /mail/box

[boyd, rounin]

> ... Google already has archives going back years; ...

say hi to mike burrows from me rob.

Re: [9fans] permission bit of /mail/box

[andrey mirtchovski]

On Wed, 24 Sep 2003 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> However, I feel it's not the way of Plan 9 which seaks most
> elegant way to solve ones.

I believe Presotto's reasoning was exactly that -- there is no easy and
intuitive way to implement a 'do-not-archive' bit. At least not intuitive
to the users.

People are used to /scratch space already on other systems, just in Plan 9
it would mean 'this will not be backed up, but you could bind it anywhere you
like'. A reverse /tmp of sorts :)

I'm so happy to have the 'always archive' option with venti that I don't
mind it requiring me to be a wee bit careful where I put mp3's :)

Re: [9fans] permission bit of /mail/box

[okamoto]

> We keep a separate file system that isn't backed up.  Many people
> here keep there /usr/xxx/tmp there,

If do so, the 'other' file system looks like "garbage" to me.
It doesn't cause any problem.., yes, I agree.
However, I feel it's not the way of Plan 9 which seaks most
elegant way to solve ones.
Then, I asked why we don't use noarchive flag in main filesystem.
The other filesystem can be used for such as spaces for database,
common to whole the system, and of course, for swap etc.

Am I thinkng wrong?

Kenji

Re: [9fans] permission bit of /mail/box

[Scott Schwartz]

| > curiously the full archive starts in Sep 2000
|
| That corresponds to about the time the CompSci department at Penn State
| switched from Majordomo to Mailman.

Yes.  Earlier archives are on my web page.

Re: [9fans] permission bit of /mail/box

[boyd, rounin]

> google groups

complete with qualude and burrows.

Re: [9fans] permission bit of /mail/box

[matt]

> For years I've been meaning to create a searchable archive of 9fans.
> (It's not a difficult thing to do.

hget -o 9fans.mbox https://lists.cse.psu.edu/archives/9fans.mbox/9fans.mbox

keeps a local version of the full archive in sync

If you were feeling adventurous you could even do

upas/fs -f 9fans.mbox

curiously the full archive starts in Sep 2000

Re: [9fans] permission bit of /mail/box

[Dan Cross]

> > For years I've been meaning to create a searchable archive of 9fans.
> > (It's not a difficult thing to do.
>
> hget -o 9fans.mbox https://lists.cse.psu.edu/archives/9fans.mbox/9fans.mbox
>
> keeps a local version of the full archive in sync

That's not very centralized.  By definition, I realize, but still.

> If you were feeling adventurous you could even do
>
> upas/fs -f 9fans.mbox

And use up a lot of memory....  Actually, everyone would use up a lot
of memory.  Ick.

> curiously the full archive starts in Sep 2000

That corresponds to about the time the CompSci department at Penn State
switched from Majordomo to Mailman.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[matt]

> For years I've been meaning to create a searchable archive of 9fans.
> (It's not a difficult thing to do.

hget -o 9fans.mbox https://lists.cse.psu.edu/archives/9fans.mbox/9fans.mbox

keeps a local version of the full archive in sync

If you were feeling adventurous you could even do

upas/fs -f 9fans.mbox

curiously the full archive starts in Sep 2000

Re: [9fans] permission bit of /mail/box

[Dan Cross]

mirtchov@cpsc.ucalgary.ca writes:
>
> > I've proposed getting rid of the gateway on several occasions, but
> > always met with resistance.  I say go for it.  USENET couldn't even
> > charitably be considered the CB radio of the Internet now.
>
> i search on google news all the time, and only the 9fans archive --
> wouldn't like to see that go...
>
> i'd say strip the email is a better idea.  even if not stripped on the
> psu.edu archive site that's still an improvement.
>
> by the way, if you look at pse.edu archives of 9fans you'll see that
> messages appear to contain only 9fans@cse address, so the only thing
> you're left with, that contains the original poster's email address,
> are the raw mailbox archives there.
>
> Judging from the fact that none of the addresses i've previously
> posted to 9fans from are affected (i.e.  the virus can find only the most
> recent posts on usenet), i'd say substituting something bogus at the
> usenet gateway will fix at least 90% of our problems...

For years I've been meaning to create a searchable archive of 9fans.
(It's not a difficult thing to do, I've just been too lazy to actually
do it.)  If a decent interface to search the list archives existed, I
don't think it'd be a big deal to turn off the usenet gateway.  One
could make it password protected, but anyone could get a password
automatically, to defeat the automated harvesters.

But I question whether it would fix the spam problem.  Google already
has archives going back years; one can't really get rid of those, and
they contain many addresses that are still valid.

Btw- while the `archiver' thing mailman uses on lists.cse.psu.edu sucks,
there is a link to the ``raw mailbox'' or some such there, from whence
you can download the entire archives of 9fans since it was moved to
mailman.  That contains full headers.  Further, Scott has links to older
archives on his web page, if I'm not mistaken.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[mirtchov]

> I've proposed getting rid of the gateway on several occasions, but
> always met with resistance.  I say go for it.  USENET couldn't even
> charitably be considered the CB radio of the Internet now.

i search on google news all the time, and only the 9fans archive --
wouldn't like to see that go...

i'd say strip the email is a better idea.  even if not stripped on the
psu.edu archive site that's still an improvement.

by the way, if you look at pse.edu archives of 9fans you'll see that
messages appear to contain only 9fans@cse address, so the only thing
you're left with, that contains the original poster's email address,
are the raw mailbox archives there.

Judging from the fact that none of the addresses i've previously
posted to 9fans from are affected (i.e.  the virus can find only the most
recent posts on usenet), i'd say substituting something bogus at the
usenet gateway will fix at least 90% of our problems...

Re: [9fans] permission bit of /mail/box

[C H Forsyth]

>>it appears that the virus scavenges usenet for addresses,
>>at least looking at the strings in the binary.  and we're all
>>posting to usenet regularly.

i have long noticed a big increase in spam whenever i
sent something to 9fans.  i'd forgotten about the usenet
gateway.

Re: [9fans] permission bit of /mail/box

[matt]

> anybody here read usenet anymore?

google groups

Re: [9fans] permission bit of /mail/box

[Dan Cross]

I've proposed getting rid of the gateway on several occasions, but
always met with resistance.  I say go for it.  USENET couldn't even
charitably be considered the CB radio of the Internet now.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[Dan Cross]

> "Hey, those guys made fun of stallman.  Get 'em!"

This deserves inclusion in the fortune file.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[Russ Cox]

we could close the "official" gateway but
there would still be things like gmane.

Re: [9fans] permission bit of /mail/box

[ron minnich]

On Tue, 23 Sep 2003, Russ Cox wrote:

> it appears that the virus scavenges usenet for addresses,
> at least looking at the strings in the binary.  and we're all
> posting to usenet regularly.

anybody here read usenet anymore? it's tempting to start closing all these
gateways. usenet signal/noise is so darn low anyway.

ron

Re: [9fans] permission bit of /mail/box

[Russ Cox]

> we may not be the hardest hit. Oon my other email accounts there is a lot
> of filtering being done @lanl. I assume there is no filtering being done
> on your 9fans address.

it appears that the virus scavenges usenet for addresses,
at least looking at the strings in the binary.  and we're all
posting to usenet regularly.

Re: [9fans] permission bit of /mail/box

[ron minnich]

On Tue, 23 Sep 2003 mirtchov@cpsc.ucalgary.ca wrote:

> why are we hardest hit?  none of my other email addresses (which
> generally receive more spam than @cpsc.ucalgary) have had any problems
> whatsoever.  the one address I use for posting to 9fans (and pretty
> much no external communication) received 350MB worth of viruses since
> last thursday, in 2000+ messages.

we may not be the hardest hit. Oon my other email accounts there is a lot
of filtering being done @lanl. I assume there is no filtering being done
on your 9fans address.

ron

Re: [9fans] permission bit of /mail/box

[splite]

On Tue, Sep 23, 2003 at 03:29:29PM +0200, boyd, rounin wrote:
> > why are we hardest hit?
>
> 'Sender domain must resolve' = ()

All your domain are belong to VeriSign.

RE: [9fans] permission bit of /mail/box

[Tiit Lankots]

>why are we hardest hit?  none of my other email addresses (which
>generally receive more spam than @cpsc.ucalgary) have had any problems
>whatsoever.  the one address I use for posting to 9fans (and pretty
>much no external communication) received 350MB worth of viruses since
>last thursday, in 2000+ messages.

highly strange, indeed. of my company (~ 30 workers) i am the *only* one hit, 
and i'm getting about 700 viruses/day. (not to mention all the 'delivery impossible'
messages.) what's more strange, it seems that i was among the first to be hit.
i wonder if they did some email scavenging from usenet before releasing it...

Tiit

Re: [9fans] permission bit of /mail/box

[mirtchov]

> After receiving 1700 (minimum) copies of the Gibe-F/Swen virus over the
> last five days, I'll go for almost *anything*.

why are we hardest hit?  none of my other email addresses (which
generally receive more spam than @cpsc.ucalgary) have had any problems
whatsoever.  the one address I use for posting to 9fans (and pretty
much no external communication) received 350MB worth of viruses since
last thursday, in 2000+ messages.

Re: [9fans] permission bit of /mail/box

[boyd, rounin]

> why are we hardest hit?

'Sender domain must resolve' = ()

Re: [9fans] permission bit of /mail/box

[Russ Cox]

if you pull the current mail/lib/pipeto.lib, you can add

	if(isvirus)
		exit 0

to your pipeto files in order to drop this
particular virus on the ground before it
gets to your mailbox.  dave is also experimenting
with dropping executable attachments.

Re: [9fans] permission bit of /mail/box

[Sam]

> why are we hardest hit?  none of my other email addresses (which

I'm sure it has nothing to do with our community's
tendency to lambast uneducated dissenters on their
pilgrimage for the one true license.

"Hey, those guys made fun of stallman.  Get 'em!"

"YEAH!"

"... but they're smarter than us, boss ... "

"well, then, let's spam 'em!"

"YEAH!"

The events, characters and situations in this story
are fictitious.  Any similarity to actual persons, living
or dead, or to actual events is purely coincidental.

Sam

Re: [9fans] permission bit of /mail/box

[Joel Salomon]

> I am linking non-SMTP approaches to email more and more. importing
s/linking/liking/ ?
> /mail/box from 9grid is working well at present.

After receiving 1700 (minimum) copies of the Gibe-F/Swen virus over the
last five days, I'll go for almost *anything*.

Someone *please* implement import /mail/box in a non-p9 mail client - SMTP
deserves a decent burial, but it needs to be killed off first.

--Joel

Re: [9fans] permission bit of /mail/box

[ron minnich]

well, I have stopped even looking at posts to my mailing lists from
non-subscribers.

I am linking non-SMTP approaches to email more and more. importing
/mail/box from 9grid is working well at present.

ron

Re: [9fans] permission bit of /mail/box

[Douglas A. Gwyn]

Dennis Ritchie wrote:
> And some in Gov't situations were rather taken
> aback to discover that mail they thought they'd
> deleted was in fact archived.

In fact there is a legal requirement to archive it all.
I think that was reinterpreted to include only material
involved in formulating "executive decisions".

Re: [9fans] permission bit of /mail/box

[Kenji Arisawa]

> BTW, we're receiving *a*lot* of fake upgrade/patch/download mails
> pretending to be from MS; i.e. 50M just for me just the last
> weekend. I resorted to /mail/lib/patters because the spam filter
> does not seem to be enough by now to stop it. Is the same happening
> to you?

I received 44MB mails in a night.

bash$ ls -l
...
-rw--w----  1 arisawa  wheel  44534584 Sep 23 08:20 mbox
...
bash$ grep '^From ' mbox > x
bash$ wc x
      360    3960   25975 x
bash$ cat x
 From mpgv.com!pkotula Tue Sep 23 00:11:21 JST 2003 remote from ar
...
 From earthlink.net!gillouise Tue Sep 23 07:56:00 JST 2003 remote from ar
bash$

Mails that is really for me were only 5.

bash$ grep 9fans x
 From cse.psu.edu!9fans-admin Tue Sep 23 00:31:31 JST 2003 remote from ar
 From cse.psu.edu!9fans-admin Tue Sep 23 00:44:39 JST 2003 remote from ar
 From cse.psu.edu!9fans-admin Tue Sep 23 01:57:43 JST 2003 remote from ar
 From cse.psu.edu!9fans-admin Tue Sep 23 02:53:41 JST 2003 remote from ar
 From cse.psu.edu!9fans-admin Tue Sep 23 04:38:47 JST 2003 remote from ar
bash$

It seems /mail/lib/blocked is ineffective to block these SPAM.
I don't know the reason.

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[Kenji Arisawa]

> BTW, we're receiving *a*lot* of fake upgrade/patch/download mails
> pretending to be from MS; i.e. 50M just for me just the last
> weekend. I resorted to /mail/lib/patters because the spam filter
> does not seem to be enough by now to stop it. Is the same happening
> to you?

I received 44MB mails in a night.

bash$ ls -l
...
-rw--w----  1 arisawa  wheel  44534584 Sep 23 08:20 mbox
...
bash$ grep '^From ' mbox > x
bash$ wc x
      360    3960   25975 x
bash$ cat x
 From mpgv.com!pkotula Tue Sep 23 00:11:21 JST 2003 remote from ar
...
 From earthlink.net!gillouise Tue Sep 23 07:56:00 JST 2003 remote from ar
bash$

Mails that is really for me were only 5.

bash$ grep 9fans x
 From cse.psu.edu!9fans-admin Tue Sep 23 00:31:31 JST 2003 remote from ar
 From cse.psu.edu!9fans-admin Tue Sep 23 00:44:39 JST 2003 remote from ar
 From cse.psu.edu!9fans-admin Tue Sep 23 01:57:43 JST 2003 remote from ar
 From cse.psu.edu!9fans-admin Tue Sep 23 02:53:41 JST 2003 remote from ar
 From cse.psu.edu!9fans-admin Tue Sep 23 04:38:47 JST 2003 remote from ar
bash$

It seems /mail/lib/blocked is ineffective to block these SPAM.
I don't know the reason.

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[boyd, rounin]

> - take the disks into a parking lot, run over with tank.
> - put the disks on top of a *REALY* big magnet. The one the user had
>   was so strong it bent the platters.

thermite grenade.

Re: [9fans] permission bit of /mail/box

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 94 bytes --]

the problem was that the mbox got just too big for the memory
we use to have. that was all.

[-- Attachment #2: Type: message/rfc822, Size: 2829 bytes --]

From: "Joel Salomon" <salomo3@cooper.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] permission bit of /mail/box
Date: Mon, 22 Sep 2003 10:30:33 -0400 (EDT)
Message-ID: <1447.199.98.17.56.1064241033.squirrel@wish>


Fco.J.Ballesteros said:
> BTW, we're receiving *a*lot* of fake upgrade/patch/download mails
> pretending to be from MS; i.e. 50M just for me just the last
> weekend. I resorted to /mail/lib/patters because the spam filter
> does not seem to be enough by now to stop it. Is the same happening
> to you?
>
Since these mails are substantially identical, is the problem the 50MB
(which should compact to 5-6 versions of the 140kb virus) or the clutter
in the directory tree?

--Joel

Re: [9fans] permission bit of /mail/box

[Dan Cross]

Dennis Ritchie <dmr@plan9.bell-labs.com> writes:
>
>  > actually in many Gov't situations, a mail system that made mail
>  > un-deletable would be considered a huge plus.
>
> And some in Gov't situations were rather taken
> aback to discover that mail they thought they'd
> deleted was in fact archived.

Some CEO's, too, as US Marshalls led them out of their offices in
handcuffs.  Score one for the little guy!

	- Dan C.

Re: [9fans] permission bit of /mail/box

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

We keep a separate file system that isn't backed up.  Many people
here keep there /usr/xxx/tmp there, both to avoid filling up
the dump with trash and to have someplace to put files that
they don't want trapped in amber.  You could easily put mail
files there also, given the correct bind's in /lib/namespace.

[-- Attachment #2: Type: message/rfc822, Size: 2118 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] permission bit of /mail/box
Date: Mon, 22 Sep 2003 10:58:04 +0900
Message-ID: <b94fb430b6596e3d1b0aa192550d9a24@granite.cias.osakafu-u.ac.jp>

> actually in many Gov't situations, a mail system that made mail
> un-deletable would be considered a huge plus.

Actually, I smelled this kind of philosopy to my discussion that
we should give an oppotunity not to make archive something.
At least, the user should be able to choose it.

Kenji

Re: [9fans] permission bit of /mail/box

[Joel Salomon]

> - take the disks into a parking lot, run over with tank.
> - put the disks on top of a *REALY* big magnet. The one the user had
>   was so strong it bent the platters.

OK, now how do I protect myself without destroying my system?

Threaten the luser with dismemberment and defenestration if he saves
copyrighted stuff, probably.

--Joel

Re: [9fans] permission bit of /mail/box

[ron minnich]

On Mon, 22 Sep 2003, Joel Salomon wrote:

> That question occurred to me as well. Say a user downloads some gigabytes
> of RIAA bait. Since the next, greatest, version of file-swapping software
> is a 9p application ;) , how do I delete the files to comply with a court
> order?

as per a note on usenet a long, long time ago:

- take the disks into a parking lot, run over with tank.
- put the disks on top of a *REALY* big magnet. The one the user had
  was so strong it bent the platters.

ron

Re: [9fans] permission bit of /mail/box

[Joel Salomon]

Fco.J.Ballesteros said:
> BTW, we're receiving *a*lot* of fake upgrade/patch/download mails
> pretending to be from MS; i.e. 50M just for me just the last
> weekend. I resorted to /mail/lib/patters because the spam filter
> does not seem to be enough by now to stop it. Is the same happening
> to you?
>
Since these mails are substantially identical, is the problem the 50MB
(which should compact to 5-6 versions of the 140kb virus) or the clutter
in the directory tree?

--Joel

Re: [9fans] permission bit of /mail/box

[Joel Salomon]

okamoto@granite.cias.osakafu-u.ac.jp said:
> I'm receiving thousands of junk mails describing MS Custermer etc.
> I think those are definetly junks and never to go archive.   Some students
> may gather some kinds of pictures in his home directory.   Those must
> not be archived!
>
That question occurred to me as well. Say a user downloads some gigabytes
of RIAA bait. Since the next, greatest, version of file-swapping software
is a 9p application ;) , how do I delete the files to comply with a court
order?

Worst case scenario, but...

--Joel

Re: [9fans] permission bit of /mail/box

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

Its easy enough to throw one liners at fossilcons by just using echo.
With a tiny little wrapper, you can even deal with errors.  If you want
to write a shell script that does a whole bunch of stuff, this is a
better way to do it than turning fossilcons into another emacs.

[-- Attachment #2: Type: message/rfc822, Size: 2093 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] permission bit of /mail/box
Date: Sun, 21 Sep 2003 22:22:56 -0400
Message-ID: <20030922022256.29166.qmail@g.bio.cse.psu.edu>

| Yeah.  Maybe fossilcons could be replaced by an rc in a sandbox with
| nothing but fossil `commands' and scripts in it.

Maybe we're reinventing tcl---the lean original before it tried
to compete with perl.

Re: [9fans] permission bit of /mail/box

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 43 bytes --]

You going to fix the error message problem?

[-- Attachment #2: Type: message/rfc822, Size: 2512 bytes --]

From: "Russ Cox" <rsc@mit.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] permission bit of /mail/box
Date: Mon, 22 Sep 2003 02:51:09 -0400
Message-ID: <cc1e9756d02133102963b27c8ef5a7d8@plan9.bell-labs.com>

> Both are not wrong.
> User must know what s/he did on his/her home directory.

If accessing /n/dump/2003/0921/usr/r/lib/profile fails
because .../usr/r does not exist, then the error should
say '/usr/r does not exist' instead of saying
'/usr/r/lib/profile does not exist'.  Both messages are
true, but the first is more specific and thus more useful.
The kernel used to produce the first message, but now
produces the second.

> Is it really difficult, once again?

I meant to finish my last message with this point but I got
sidetracked by the error message not being what I expected.

I think the noarchive bit would be trivial to implement -- the
necessary code already exists in order to avoid archiving /n/snap.
I'm just not sure it's a good idea.

Russ

Re: [9fans] permission bit of /mail/box

[Bruce Ellis]

there are goofy laws here where some things must be kept for
seven years and other things must be expelled after seven.
they [banks] use warehouses full of elves and are a difficult sell.

brucee
----- Original Message -----
From: "Dennis Ritchie" <dmr@plan9.bell-labs.com>
To: <9fans@cse.psu.edu>
Sent: Monday, September 22, 2003 3:00 PM
Subject: Re: [9fans] permission bit of /mail/box


> > actually in many Gov't situations, a mail system that made mail
>  > un-deletable would be considered a huge plus.
>
> And some in Gov't situations were rather taken
> aback to discover that mail they thought they'd
> deleted was in fact archived.

Re: [9fans] permission bit of /mail/box

[boyd, rounin]

From: "Laura Creighton" <lac@strakt.com>
>
> Any time you want to buy a CAPS system, Ron, you know where to find
> us :-)

yeah, i recall something about a thing called the IFC:

    http://www.strakt.com/docs/IFC200304.pdf

Re: [9fans] permission bit of /mail/box

[okamoto]

>Someday they would
> notice that their deeds cannot be undone.  not if throwing
> the disk into the fire of Mount Doom.

If he could ne Einstein, it may be.
However, most cases, they are not.  ☺

Kenji

Re: [9fans] permission bit of /mail/box

[okamoto]

> We use the not-archived file system here for /mail/box, for secstore, for
> /sys/log, for a per-user directory to keep big stuff, for /n/music
> files and the like. 

What must be a beautifule file tree of 'other' file system! ☺

Kenji

Re: [9fans] permission bit of /mail/box

[YAMANASHI Takeshi]

"On Mon Sep 22 16:13:37 JST 2003, okamoto@granite.cias.osakafu-u.ac.jp wrote:"
> I'm receiving thousands of junk mails describing MS Custermer etc.
> I think those are definetly junks and never to go archive.

It is ok those junk mail to be archived.  Those disk blocks will
never (in practical meaning :) be used unless the bunch of junk
is received.


> Some students
> may gather some kinds of pictures in his home directory.

However, this case could be different.  Someday they would
notice that their deeds cannot be undone.  not if throwing
the disk into the fire of Mount Doom.
--

Re: [9fans] permission bit of /mail/box

[Fco.J.Ballesteros]

We use the not-archived file system here for /mail/box, for secstore, for
/sys/log, for a per-user directory to keep big stuff, for /n/music
files and the like. It's been a big success. Since the fs is still
in a mirror, we feel kind of secure about the data on it, but we dont
get all the useless stuff into venti. If you havent tried it, give it
a try for a while and IMHO you'll never want to get back to using just
a main file system.

Re: [9fans] permission bit of /mail/box

[okamoto]

> weekend. I resorted to /mail/lib/patters because the spam filter
> does not seem to be enough by now to stop it. Is the same happening
> to you?

When I logged in to my 9terminal this morning.
I thought something wrong happened to our system.
It's too much of junk mails such as MS Custermer, Update, returned
mail...

As long as the noarchive bit concerns, I believe it's worth to have
some test implementation to our fossil server.   After that, then we
can decide which is better.   To have a 'other' file system is not a
bad idea at now.  Because we have no other choise.   However, if we
don't have problem when we have that bit installed,  it looks like not
so cool solution to me.

Kenji

Re: [9fans] permission bit of /mail/box

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

The problem is how do you know what's junk and what's not without
requiring human intervention. For example, it's nice to have
a different not archived fs because users know that all in the
main one gets archived; thus there's no opportunity for them to
forget to set the noarchive bit. I thought of adding the noarchive
bit, to unify our main (archived) and once (not archived) file systems;
but after thinking twice, I thought users would forget to set the bit
on tars downloaded and the like.

Regarding abusing the dump, i.e. student homes, right now their
homes here are in a not archived file system. Next semester I'm
going to experiment with putting them in a fossil with snap but
without archiving.

BTW, we're receiving *a*lot* of fake upgrade/patch/download mails
pretending to be from MS; i.e. 50M just for me just the last
weekend. I resorted to /mail/lib/patters because the spam filter
does not seem to be enough by now to stop it. Is the same happening
to you?

[-- Attachment #2: Type: message/rfc822, Size: 2377 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] permission bit of /mail/box
Date: Mon, 22 Sep 2003 16:12:59 +0900
Message-ID: <018171da47f1d62ed7e0278bf14eb90c@granite.cias.osakafu-u.ac.jp>

> I think the noarchive bit would be trivial to implement -- the
> necessary code already exists in order to avoid archiving /n/snap.
> I'm just not sure it's a good idea.

I expected this answer.

I think it depends on how we consider what is junk.   I believe there
are many junks in the real world, and we should be able to judge which is
junk or not by ourselves when it is concerned ourselves at least.

I'm receiving thousands of junk mails describing MS Custermer etc.
I think those are definetly junks and never to go archive.   Some students
may gather some kinds of pictures in his home directory.   Those must
not be archived!

Kenji

Re: [9fans] permission bit of /mail/box

[okamoto]

> I think the noarchive bit would be trivial to implement -- the
> necessary code already exists in order to avoid archiving /n/snap.
> I'm just not sure it's a good idea.

I expected this answer.

I think it depends on how we consider what is junk.   I believe there
are many junks in the real world, and we should be able to judge which is
junk or not by ourselves when it is concerned ourselves at least.

I'm receiving thousands of junk mails describing MS Custermer etc.
I think those are definetly junks and never to go archive.   Some students
may gather some kinds of pictures in his home directory.   Those must
not be archived!

Kenji

Re: [9fans] permission bit of /mail/box

[Russ Cox]

> Both are not wrong.
> User must know what s/he did on his/her home directory.

If accessing /n/dump/2003/0921/usr/r/lib/profile fails
because .../usr/r does not exist, then the error should
say '/usr/r does not exist' instead of saying
'/usr/r/lib/profile does not exist'.  Both messages are
true, but the first is more specific and thus more useful.
The kernel used to produce the first message, but now
produces the second.

> Is it really difficult, once again?

I meant to finish my last message with this point but I got
sidetracked by the error message not being what I expected.

I think the noarchive bit would be trivial to implement -- the
necessary code already exists in order to avoid archiving /n/snap.
I'm just not sure it's a good idea.

Russ

Re: [9fans] permission bit of /mail/box

[Laura Creighton]

>actually in many Gov't situations, a mail system that made mail
>un-deletable would be considered a huge plus.

Any time you want to buy a CAPS system, Ron, you know where to find
us :-)  (Though having received over 3000 copies of the blaster
worm this weekend has convinced me that anybody, who like us offers
this has got to have a 'this mail is virtually identical to
that mail, so just store one copy and make a database link' option.)

Laura

Re: [9fans] permission bit of /mail/box

[Kenji Arisawa]

Russ Cox:
> It is not at clear to me that an "no archive" bit is such
> a good idea.  My main objection is that it is implicit -- if
> I set the bit for /usr/rsc, it's hard to see quickly that
> /usr/rsc/lib/profile is not archived.

I think "no archive" bit is not allowed directory if we introduce it,
though I am skeptical about the necessity of the bit.

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[okamoto]

> It is not at clear to me that an "no archive" bit is such
> a good idea.  My main objection is that it is implicit -- if
> I set the bit for /usr/rsc, it's hard to see quickly that
> /usr/rsc/lib/profile is not archived.

Really?
I thought it must be done easily.  Of course, I have no good
knowledge of it.  Is it really difficult?   All the default setting
is going to archive, and only some directories, (or it should be
confined to files only, I'm not sure yet), will be set by the user
to no archive.   Of if a directory is set so, underlying directories
must be so.   If it's not easy to many user, s/he will not use it.
It's not important.   The point is there is such an oppotunity
to trained user.  It's freedom to use that operating system related,
I believe.

> Then again, we already
> have this property with walk -- if I chmod 700 /usr/rsc then
> even if /usr/rsc/lib/profile is mode 666, no one else can edit it.
> Further, if you wondered why "cat `{yesterday lib/profile}" wasn't
> working, it would tell you:
>
> 	glenda% cat `{yesterday /usr/r/lib/profile}
> 	cat: can't open /n/dump/2003/0921/usr/r/lib/profile:
> 		'/n/dump/2003/0921/usr/r' does not exist
> 	glenda%
>
> or at least it should -- the error-generating code appears
> not to be working properly.  It actually says:
>
> 	glenda% cat `{yesterday /usr/r/lib/profile}
> 	cat: can't open /n/dump/2003/0921/usr/r/lib/profile:
> 		'/n/dump/2003/0921/usr/r/lib/profile' does not exist
> 	glenda%
>
> which is wrong.

Both are not wrong.
User must know what s/he did on his/her home directory.

Is it really difficult, once again?

Kenji

Re: [9fans] permission bit of /mail/box

[Russ Cox]

It is not at clear to me that an "no archive" bit is such
a good idea.  My main objection is that it is implicit -- if
I set the bit for /usr/rsc, it's hard to see quickly that
/usr/rsc/lib/profile is not archived.  Then again, we already
have this property with walk -- if I chmod 700 /usr/rsc then
even if /usr/rsc/lib/profile is mode 666, no one else can edit it.
Further, if you wondered why "cat `{yesterday lib/profile}" wasn't
working, it would tell you:

	glenda% cat `{yesterday /usr/r/lib/profile}
	cat: can't open /n/dump/2003/0921/usr/r/lib/profile:
		'/n/dump/2003/0921/usr/r' does not exist
	glenda%

or at least it should -- the error-generating code appears
not to be working properly.  It actually says:

	glenda% cat `{yesterday /usr/r/lib/profile}
	cat: can't open /n/dump/2003/0921/usr/r/lib/profile:
		'/n/dump/2003/0921/usr/r/lib/profile' does not exist
	glenda%

which is wrong.

Russ

Re: [9fans] permission bit of /mail/box

[Geoff Collyer]

Russ tells me that one can run a fossil filesystem with just a write
buffer and no venti backing store to get the effect of the `other'
file system on Ken's file server.  So if you have a normal fossil
`main' file system using venti as backing store and an `other' file
system without venti backing store, you can put your /mail or
/mail/box on `other' and bind -c it over /mail or /mail/box
respectively in /lib/namespace.local, and you've got the effect you
want, if I understand you correctly.

Re: [9fans] permission bit of /mail/box

[Kenji Arisawa]

okamoto said:
> I'm not a kernel person, however, I suppose we can do it
> without not so much efforts (Oh!, please don't ask myself to do
> it, because it's beyond my ability).   When count a reference
> in fossil server, make a flag which indicates not to go archive,
> and those files/directories should not be archived.  Those directoies
> should be confined only under /usr/$user directory.   If a user
> doesn't set that flag, all goes to archive.

We can introduce archive flag like MS-DOS.
The question is "Is it worth introducing the flag?"
What kinds of files do you want not to be archived except mails?

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[Ronald G. Minnich]

On Mon, 22 Sep 2003, Dennis Ritchie wrote:

>  > actually in many Gov't situations, a mail system that made mail
>  > un-deletable would be considered a huge plus.
>
> And some in Gov't situations were rather taken
> aback to discover that mail they thought they'd
> deleted was in fact archived.


yeah, that's always a good time when that happens :-)

ron

Re: [9fans] permission bit of /mail/box

[Dennis Ritchie]

 > actually in many Gov't situations, a mail system that made mail
 > un-deletable would be considered a huge plus.

And some in Gov't situations were rather taken
aback to discover that mail they thought they'd
deleted was in fact archived.

Re: [9fans] permission bit of /mail/box

[okamoto]

>> Actually, I smelled this kind of philosopy to my discussion that
>> we should give an oppotunity not to make archive something.
>> At least, the user should be able to choose it.
>
> but then you need a user interface to make the choice.  not worth
> it. just archive everything.

I'm not a kernel person, however, I suppose we can do it
without not so much efforts (Oh!, please don't ask myself to do
it, because it's beyond my ability).   When count a reference
in fossil server, make a flag which indicates not to go archive,
and those files/directories should not be archived.  Those directoies
should be confined only under /usr/$user directory.   If a user
doesn't set that flag, all goes to archive.

On such a fossil, I can live with very comfortablly.
Am I thinking wrong?

Kenji

Re: [9fans] permission bit of /mail/box

[Kenji Arisawa]

  YAMANASHI Takeshi:
> "On Sun Sep 21 21:33:30 JST 2003, arisawa@ar.aichi-u.ac.jp wrote:"
>> I think it is convenient if /mail/box/$user is automatic created
>> at the time when /usr/$user is created.
>
> I'm afraid to contradict you,

Not contradicted. I don't said mail box should be archived.
I don't hope my mail is archived nor stored in public machine.
I always forward my mail to my personal machine.

Dan C:
> Yeah.  Maybe fossilcons could be replaced by an rc in a sandbox with
> nothing but fossil `commands' and scripts in it.

More strong and comfortable administration may be:
"nemo's single-user-allow  fossilcons" + "deletion allowing archiver"

Kenji Arisawa

Re: [9fans] permission bit of /mail/box

[Rob Pike]

> Actually, I smelled this kind of philosopy to my discussion that
> we should give an oppotunity not to make archive something.
> At least, the user should be able to choose it.

but then you need a user interface to make the choice.  not worth
it. just archive everything.

-rob

Re: [9fans] permission bit of /mail/box

[Scott Schwartz]

| Yeah.  Maybe fossilcons could be replaced by an rc in a sandbox with
| nothing but fossil `commands' and scripts in it.

Maybe we're reinventing tcl---the lean original before it tried
to compete with perl.

Re: [9fans] permission bit of /mail/box

[okamoto]

> actually in many Gov't situations, a mail system that made mail
> un-deletable would be considered a huge plus.

Actually, I smelled this kind of philosopy to my discussion that
we should give an oppotunity not to make archive something.
At least, the user should be able to choose it.

Kenji

Re: [9fans] permission bit of /mail/box

[ron minnich]

On Sun, 21 Sep 2003, Dan Cross wrote:

> I kind of like the idea that I can get my mail back after I delete it,
> but I don't have much of a sensitive nature sitting in my mailbox, as
> a general rule.  I guess I'm just not that interesting of a person.  :-)

actually in many Gov't situations, a mail system that made mail
un-deletable would be considered a huge plus.

ron

Re: [9fans] permission bit of /mail/box

[okamoto]

> OKay.  I (alone it seems :) am not comfortable with the
> situation that /mail sits on fossil and some sensitive
> mail can remain on the venti forever after a snapshot.

No, you are not alone.   It I suppose belonging to some philosophical
point.   Is there any information which has no value?   Yes, I think it is.
Don't force me into another one's philosophy.

Kenji

Re: [9fans] permission bit of /mail/box

[Jim Choate]

On Sun, 21 Sep 2003, Dan Cross wrote:

> > OKay.  I (alone it seems :) am not comfortable with the
> > situation that /mail sits on fossil and some sensitive
> > mail can remain on the venti forever after a snapshot.
>
> I kind of like the idea that I can get my mail back after I delete it,
> but I don't have much of a sensitive nature sitting in my mailbox, as
> a general rule.  I guess I'm just not that interesting of a person.  :-)

Encrypt the mailbox.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] permission bit of /mail/box

[Dan Cross]

> OKay.  I (alone it seems :) am not comfortable with the
> situation that /mail sits on fossil and some sensitive
> mail can remain on the venti forever after a snapshot.

I kind of like the idea that I can get my mail back after I delete it,
but I don't have much of a sensitive nature sitting in my mailbox, as
a general rule.  I guess I'm just not that interesting of a person.  :-)

> By the way, is there a way to delete all instances of
> a file on venti completely?

Good question.  There was not with the old fileserver, but I remember
thinking it might be a good thing for a pseudo-worm at different points
in time.

I suppose, with venti, the idea is sort of moot; I think of venti as
an associative store, so data names its address anyway.  If one treats
venti as a black box, just knowing where the data is on disk implies
that you already have it.  Of course, in practice, it's not quite so
simple, since the address space of venti hugely outstraps the size of
any storage device, and we have indexes that match up block signatures
to actual addresses.  I suppose the idea of a tool to delete certain
(signature,address) pairs from the index wouldn't be bad.  Making it
delete all such pairs associated with a file (perhaps scrubbing the
reclaimed blocks) seems like it should be easy, and would solve the
problem nicely.

> > Or maybe add a small script
> > function or macro facility to the command interpreter on the filesystem
> > But then, we're getting pretty close to something like a real
> > shell.
>
> Yes, looks like a shell.  I would like to leave the job to
> the existing shell 'rc' rather than complicating kfscmd
> and fossilcons.

Yeah.  Maybe fossilcons could be replaced by an rc in a sandbox with
nothing but fossil `commands' and scripts in it.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[YAMANASHI Takeshi]

"On Mon Sep 22 07:01:30 JST 2003, cross@math.psu.edu wrote:"
> In maybe the most common case, /mail and /usr are on the
> same filesystem, so creating them at the same time wouldn't hurt anything
> and might help some.

OKay.  I (alone it seems :) am not comfortable with the
situation that /mail sits on fossil and some sensitive
mail can remain on the venti forever after a snapshot.

By the way, is there a way to delete all instances of
a file on venti completely?


> Or maybe add a small script
> function or macro facility to the command interpreter on the filesystem
> But then, we're getting pretty close to something like a real
> shell.

Yes, looks like a shell.  I would like to leave the job to
the existing shell 'rc' rather than complicating kfscmd
and fossilcons.
--

Re: [9fans] permission bit of /mail/box

[Dan Cross]

> I'm afraid to contradict you, but /mail and /usr is not
> necessarily on the same file system.  And more, this should
> be relevant to the cron directory too.

Good point, but I'd respectfully point out that in that case, it wouldn't
really matter.  In maybe the most common case, /mail and /usr are on the
same filesystem, so creating them at the same time wouldn't hurt anything
and might help some.  Perhaps a good solution would be to make the newuser
command somewhat scriptable, so it could create directories and the like
on the appropriate filesystems all at once.  Or maybe add a small script
function or macro facility to the command interpreter on the filesystem
console.  But then, we're getting pretty close to something like a real
shell.

	- Dan C.

Re: [9fans] permission bit of /mail/box

[Jim Choate]

On Mon, 22 Sep 2003, YAMANASHI Takeshi wrote:

> "On Sun Sep 21 21:33:30 JST 2003, arisawa@ar.aichi-u.ac.jp wrote:"
> > I think it is convenient if /mail/box/$user is automatic created
> > at the time when /usr/$user is created.
>
> I'm afraid to contradict you, but /mail and /usr is not
> necessarily on the same file system.  And more, this should
> be relevant to the cron directory too.

Perhaps, but that is clearly the long way around the bend.

The reasonable appreoach is exactly what Yamanashi Takeshi wrote, If
you're going to create users then mount all the relevant namespaces and
do it at one time - and then test it. That way you don't get trouble calls
later on down the road.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] permission bit of /mail/box

[YAMANASHI Takeshi]

"On Sun Sep 21 21:33:30 JST 2003, arisawa@ar.aichi-u.ac.jp wrote:"
> I think it is convenient if /mail/box/$user is automatic created
> at the time when /usr/$user is created.

I'm afraid to contradict you, but /mail and /usr is not
necessarily on the same file system.  And more, this should
be relevant to the cron directory too.
--