|
|
| Author |
Message |
| 25 new of 123 responses total. |
dam
|
|
response 50 of 123:
| 
Aug 2 23:53 UTC 1995 |
Re#45 - some of the jpg's suggested that they were 'rated r and x'.
but there only appear to be about 100 .jpg's.
|
scg
|
|
response 51 of 123:
|
Aug 3 02:31 UTC 1995 |
I don't see why we have to protect people from things in other peoples' home
directories, when people are perfectly capable of protecting themselves by
not looking. I will have very little sympathy for a user who goes around
looking for smut, and then complains when they find it.
|
rcurl
|
|
response 52 of 123:
|
Aug 3 04:34 UTC 1995 |
So, you won't sympathize with reporters from the Observer that do
that, and write up a sensational article about what they find?
|
popcorn
|
|
response 53 of 123:
|
Aug 3 12:42 UTC 1995 |
This response has been erased.
|
davel
|
|
response 54 of 123:
|
Aug 3 19:57 UTC 1995 |
Thanks. That makes sense.
|
kentn
|
|
response 55 of 123:
|
Aug 5 00:36 UTC 1995 |
Does the locate database really list *all* the files on Grex? That
seems like an invasive use of root--if the rest of us can snoop through
that list. That is, we set our perms sometimes so people can't see
what's in a directory. This database appears to override our perms
(something that root can do that the average user can't). Is this the
case?
|
ajax
|
|
response 56 of 123:
|
Aug 5 03:32 UTC 1995 |
That is the case, for better or worse. It's useful for roots, but
a more limited database might be more appropriate for normal users.
A reason I've heard not to do this (have an all-encompassing and a
limited database) is that updating the locate database is a really
big cpu hog, so running it more than once a night would be a burdon.
Re 51, Steve, I share your non-sympathy for what people find when
they're probing around for smut. However, that is the sort of thing
the media, politicians, religious right, and paranoid parents like
to pounce on, and they can have a nasty effect. However, it looks
like Grex isn't remotely close to having a problem with this.
|
jep
|
|
response 57 of 123:
|
Aug 5 07:45 UTC 1995 |
Valerie, on M-Net we run the update.locatedb program as user
"nobody", instead of "root", so that files in directories that are not
permitted to all users do not show up in the locate listing. MIght not
this be a worthwhile approach for Grex, too?
|
gregc
|
|
response 58 of 123:
|
Aug 5 15:50 UTC 1995 |
Actually, no. The primary purpose of the locate database, is so that staff
can find the location of potentially intrusive cracker programs quickly.
If somebody broke into the system and gained root, and we had to run a "find"
on the whole filesystem, it could take hours. Orriginally, when it w
was installed, it was for this purpose. There wasn't any intention that the
regular users would use it. By the time it became a problem, I suggested we
just deny access to regular users. However, so many people had begun to use
it, we were met with cries of "no, don't take away locate!". So what do
you do? We have a conflicting set of needs:
1.) Staff needs the full database. (Orriginal purpose)
2.) Users want access for finding system stuff.
3.) Some users don't want their private files listed.
4.) Running the proicess twice each night, once to produce a "full" database,
and a second time to produce a "public only" database, just isn't feasable
from a system load standpoint. It would take too long, and use up too
muich CPU.
|
mju
|
|
response 59 of 123:
|
Aug 5 17:19 UTC 1995 |
Well, as I see it there are several options:
1.) Ignore the users who are complaining, and do nothing.
2.) Run updatedb twice, once as "nobody" and once as root. Only allow
staffers access to the root-generated database.
3.) Run updatedb once, as "nobody". Have staff figure out another way
to find suspicious files.
4.) Modify updatedb to generate two databases, a "public" database which
contains files that everyone can access, and a "private" database
which contains all files (even protected ones).
Options (1) and (2) can probably not be seriously considered, since IMHO there
is a breach of privacy in the current system. Oh, I forgot option (5), which
is to depermit "locate" to non-staffers. That isn't the most polite option,
but it's the most expedient one that solves the privacy concerns. I would
really prefer that we do (4), but that requires a staff member to make the
changes. Unless one volunteers, it probably won't get done. (Jan? srw?
Valerie?)
|
popcorn
|
|
response 60 of 123:
|
Aug 5 20:34 UTC 1995 |
This response has been erased.
|
ajax
|
|
response 61 of 123:
|
Aug 6 04:16 UTC 1995 |
As a user who likes to use locate on occasion, option 6 would work
for me...I usually use it to locate old stuff, like source files or
programs in public directories, so I don't care about daily updates.
|
srw
|
|
response 62 of 123:
|
Aug 6 07:20 UTC 1995 |
I like option 6.
|
jep
|
|
response 63 of 123:
|
Aug 7 19:53 UTC 1995 |
The updatedb program can be run separately on different filesystems,
too, with different databases created, which can be made accessible to
different people pretty easily. If the users mostly want to be able to
find files in system directories, and those directories are on filesystems
other than /home, it would be a pretty easy thing to set up, without
increasing the load at all. It would require a separate locate search for
each separate filesystem database, though.
|
kentn
|
|
response 64 of 123:
|
Aug 8 03:32 UTC 1995 |
Option 6 sounds good.
|
curby
|
|
response 65 of 123:
|
Aug 13 12:21 UTC 1995 |
Howd about:
%cat $pri_locatedb | perl -ne 'print if ( ! /.home/ );' > $pub_locatedb
It would at least answer the concerns of the privicy concerned while
still only having to run the program once...
(Please no comments about perl .vs. sed. Save that for the religous
area...)
|
tsty
|
|
response 66 of 123:
|
Aug 28 03:12 UTC 1995 |
re #58, point 4. gregc's point is valid on this particualar
architecture which is feverishly (we all hope) being brought to
a close with the Sun 4.
How much objection would there be to a dual-locate (a GoodIdea (tm))
such as suggested by jep on the next version of Grex?
|
steve
|
|
response 67 of 123:
|
Aug 29 06:10 UTC 1995 |
Locate isn't trivial in terms of CPU time. The 4/200 is supposed
to get us into a faster world where people won't have to wait 3 minutes
to bring up elm to read mail--if we increase the "government" processes
on the next Grex, we'll be back to where we started. Slow.
There is another issue here, which gets to how "private" we
want Grex to be. I am leaning towards the feeling that if you
have something that is so private that you don't want the *names*
of the files known, then it doesn't belong on an open access
public computing forum such as Grex.
We're definately closing up, too. It used to be, even
during the early days of the Internet connection, that most
people kept their .plans readable. Now, 70% keep them closed.
An additional 10% put N/A or the equivelant in them. This
really disturbs me.
|
rcurl
|
|
response 68 of 123:
|
Aug 29 06:23 UTC 1995 |
I don't see the connection between "open access" and whether everyone
can read your directory, or not. It seems to me that this is an
individual matter, and there are no social implications of it
at all. Pretty much the same goes for .plans. Why is people posting
their life's stories part of "open access"? Even in society, people
that are always telling everyone ltheir life's stories are considered bores.
What's important about "open access" is the absence of barriers to
using the system as one needs. The next stage, of a community of
users that interact with one another, is based upon open access, but
is not itself open access. This is a culture. The basis of the culture
is friendliness and cooperation: these are helped by some exchange of
personal information so, at that point, I will agree that those that
close or have nothing in their .plan, comes across as unfriendly.
|
ajax
|
|
response 69 of 123:
|
Aug 29 15:12 UTC 1995 |
I think part of the reluctance for permitting .plans is that
people don't want their number and address published. If there
were separate permissions for the type of information (hobbies,
versus home address) I think people would be more comfortable
revealing something about themselves. I've seen FAQs/intros
that recommend not revealing personal (phone/addr) info on-line,
especially for kids.
As for filenames being permitted, I don't think people have so
much to *hide*, but there's info they don't particularly want (and
don't *expect*) to be public. For example, people who separate
their mail into subdirectories in a mail directory probably don't
realize that people can see the names they chose, which usually
gives a good idea about the correspendants or subjects a person
mails about. On one hand, big deal, on the other, it's somewhat
invasive. Given a choice, I think most people would prefer such
info to be private.
|
rcurl
|
|
response 70 of 123:
|
Aug 29 18:04 UTC 1995 |
I haven't run newuser for a long time to see what information is
requested. It may be that it should be revamped. It occurred to me
after writing #68 that a lot of our new users are young adults and
teenagers, many of whom are still "rebelling" against their parents,
or whtever, and want their independence, which often means keeping their
own "space" to themselves - up to a point. However there is one opening
to that space that currently seems somewhat popular - the homepage.
Does newuser *ask* for the homepage address?
|
remmers
|
|
response 71 of 123:
|
Aug 29 18:13 UTC 1995 |
Having a publicly available tool that can show the name of every
file on the system is a double-edged sword. For instance, someone
who is using Grex for illegally distributing commercial software
could use it to see if any staffers have been making copies of
his files and therefore might be on to him.
Personally, I think people have as much right to the privacy
of the names of their files as to their contents, and we shouldn't
make a program available that in effect overrides read-depermission
of directories.
|
rcurl
|
|
response 72 of 123:
|
Aug 29 22:23 UTC 1995 |
Hear! Hear!
|
omni
|
|
response 73 of 123:
|
Aug 31 04:28 UTC 1995 |
I don't like the idea of listing my address and my phone number for
public perusal. I will give it out via e-m on request. My callsign
is right out because of the callsign server.
but my .plan is still readable
|
steve
|
|
response 74 of 123:
|
Aug 31 17:49 UTC 1995 |
Jim, this might be better answered in another item, but why
not? Your name and address are *already* publically available
in the Michigan database of Driver's licenses, your amateur radio
license, etc.
Although I haven't heard of many cases of harrassment that
involves cyberspace, of the three I know of, two of them involved
"normal" information channels as well (like the guy got the womans
address by asking the Post Office. Yes, you can find out what
information they have for you, if you give them a name; they'll
tell you the mailing address).
So the question becomes, how private is private? If the
name of a file is as private as the contents, then we have
an inherent problem with /tmp, where the names of all the
files are common knwoledge (as long as you know about ls).
Following this logic, do we depermit the "mailq" program,
so people can't see if their mail has left the system when
things get bogged down? Or do we modify mailq such that it
only shows your mail?
What about the /etc/passwd file? Therein lines the names (or
not) of the people here. I've used this file many times on
various systems trying to find matches for names. Sometimes it
works, sometimes not.
/var/spool/mail contains the mailboxes for everyone on Grex.
It indicates size. Do we disallow the information contained in
just knowing the size of a mailbox? I can deduce that a mailbox
that is nearly always at zero isn't on any mailing lists. Fatter
ones that are usually in the coupld hundred K range indicate an
active user. Really corpulent ones indicate mailing lists, usually.
Is that something we have to deal with?
Please understand that I'm not trying to be persnickety here.
I'm trying to point out all the things that might make sense
to change, if we are to start thinking about these things.
I personally don't think we should be embarking down this road.
In the United States there is a lot of information that is publically
available about you, and always has been. I see the file that
a database has the names of your files on about the same level
as the fact that the SEV (State Equalized Value) of your house
being public knowledge, and available by a phone call. While
the approximate value of your house might be known, it doesn't
say anything about the contents therein. I think the anology
between the SEV database and locate database is pretty good.
|
