|
|
| Author |
Message |
| 25 new of 147 responses total. |
valerie
|
|
response 100 of 147:
| 
Apr 9 21:37 UTC 1998 |
This response has been erased.
|
janc
|
|
response 101 of 147:
|
Apr 10 13:36 UTC 1998 |
Currently most Grex users have their home directories on the /a disk. You
may have noticed that since we switched over to the new system, there is also
a /c disk partition, which has until now been empty. As of this morning, all
new users home directories will be on the /c disk. This will keep happening
until /c is getting pretty full, at which point we will direct the hose badk
to /a.
This means that you will no longer be able to count on user "blutong" having
home directory "/a/b/l/blutong". It might be that, or it might be
"/c/b/l/blutong" or after we add more disk it might also be "/d/b/l/blutong".
This is a little confusing if you want to "cd" to someone else's home
directory. Finger will tell you where their home directory is, but you can
also "cd" to their home directory without having to know it by doing any of
the following:
cd ~blutong (this is slow in some shells)
cd /?/b/l/blutong
cd `hd blutong`
You're probably wondering what happened to the /b partition. /b is, for weird
historical reason, a link to the bbs shell, so we can't use it as a directory.
Oh well.
We don't expect to be moving users between the two disk partitions, so once
your account is created in a particular place it should stay there until
doomsday.
|
davel
|
|
response 102 of 147:
|
Apr 10 13:50 UTC 1998 |
The ~ thing doesn't work in sh.
|
valerie
|
|
response 103 of 147:
|
Apr 10 14:21 UTC 1998 |
This response has been erased.
|
dpc
|
|
response 104 of 147:
|
Apr 10 19:53 UTC 1998 |
Thanx, Valerie! How do you define "local" and "remote"?
|
gibson
|
|
response 105 of 147:
|
Apr 11 01:05 UTC 1998 |
What exactly is blutong?
|
valerie
|
|
response 106 of 147:
|
Apr 11 13:40 UTC 1998 |
This response has been erased.
|
srw
|
|
response 107 of 147:
|
Apr 12 15:52 UTC 1998 |
The locate database has been rebuilt. You should no longer get that
annoying "more than 8 days old" message. If all goes well, it will be
rebuilt regularly every Sunday morning. Users will only see files that
are in publicly scannable directories. The /c partition has been added
to the list of scanned partitions.
(It didn't happen this morning because I forgot something, but it will
next week - fingers crossed)
|
albaugh
|
|
response 108 of 147:
|
Apr 14 17:46 UTC 1998 |
Obviously you know that what could be done is to create an /a/u (/a/users)
directory and link users' home directories off it to "point" to the actual
drive & directory. E.g. /a/u/a/l/albaugh = /a/a/l/albaugh &
/a/u/b/l/blutong = /c/b/l/blutong
|
janc
|
|
response 109 of 147:
|
Apr 14 18:23 UTC 1998 |
We've thought of creating a tree of symlinks, like /home/a/l/albaugh that just
point to the real directory of the user, but it would be hard to maintain,
and would be of little use unless we actually put those paths in the passwd
file, which would add overhead into find directories. In the end, we felt
this was the simpler and more efficient way to go.
|
mcnally
|
|
response 110 of 147:
|
Apr 14 18:54 UTC 1998 |
Adding a tree of symlinks would also just add an extra potential failure
point..
|
steve
|
|
response 111 of 147:
|
Apr 18 05:32 UTC 1998 |
Grex has just passed the two week mark for continuous uptime.
We still don't know how stable this platform is and are watching
it for signs of unstability. So far it's been very good.
|
srw
|
|
response 112 of 147:
|
Apr 18 05:45 UTC 1998 |
Partial credit so far also goes to the hardware. We had spates of
instability under the old OS which probably could be attributed to flaky
old hardware box. A lot of money was spent on our new box, and we hope
this is an additional benefit of that.
|
scg
|
|
response 113 of 147:
|
Apr 18 17:52 UTC 1998 |
We didn't make it much longer. We didn't actually crash this morning, but
most of the important processes died, making the system not at all useful.
I rebooted it.
|
tsty
|
|
response 114 of 147:
|
Apr 19 19:28 UTC 1998 |
...late arrival... staff did this changeover magnificently, thankxxx.
|
valerie
|
|
response 115 of 147:
|
Apr 21 13:51 UTC 1998 |
This response has been erased.
|
albaugh
|
|
response 116 of 147:
|
Apr 21 14:32 UTC 1998 |
There was a recent, seemingly unannounced-here change that required .forward
files to be permitted world readable in order for sendmail to process them.
I guess there was some anti-spamming benefit to doing this. The downside is
the making of the .forward file world readable, which includes all grexers.
I would prefer some way of accomplishing anti-spamming without this change
required to the .forward file. Grex staffers can elaborate as they see fit.
|
scott
|
|
response 117 of 147:
|
Apr 21 17:55 UTC 1998 |
That change apparently came along with a much-updated version of sendmail,
so I'm not sure what changes *can* be made to the permissions requierment.
|
mcnally
|
|
response 118 of 147:
|
Apr 22 05:42 UTC 1998 |
is it actually necessary for the files to be world readable?
would it suffice for them to be readable by group sendmail or
group daemon or something like that?
|
valerie
|
|
response 119 of 147:
|
Apr 22 22:29 UTC 1998 |
This response has been erased.
|
fullermd
|
|
response 120 of 147:
|
Apr 23 12:16 UTC 1998 |
Hm, the version of sendmail I have on my workstation (8.8.8, I think) requires
worldreadable. So did whatever version shipped with BSDi BSD/OS 2.1 and 3.0.
Actually, every version I've ever seen required it. What version were we
running here? Should be a simple matter to write a quick sh script to recurse
through the subdirs and change the permissions, maybe mailing the user in
question (before and after changing permissions, of course) about it...?
|
albaugh
|
|
response 121 of 147:
|
Apr 23 17:51 UTC 1998 |
For my own edification: In UNIX, does root have access to any file regardless
of permissions? Does sendmail run under root? If yes & yes, you'd think it
wouldn't matter what the permissions were for the .forward file. How about
those users who have a program (procmail) in their .forward files - which
userID/account does the program run under - that of the .forward file/mail
recipient owner?
|
mcnally
|
|
response 122 of 147:
|
Apr 23 23:12 UTC 1998 |
Yes, root has access to any file regardless of permissions.
The object of this change (which, if I understand properly
was not imposed by Grex staff but is a default in new sendmail
versions) is to minimize the amount of time sendmail and
associated programs (like the local delivery agents it invokes)
must spend running in priveleged mode. If the writers can
successfully compartmentalize the priveleged operations in
one part of the program and do most things in the other part
it greatly reduces the security risk incurred during the
majority unpriveleged operations.
|
i
|
|
response 123 of 147:
|
Apr 24 01:28 UTC 1998 |
So use a SGID program in a group called forward, chgrp the
.forward files to forward, then chmod them to -rw-r-----.
A touch messy, but wouldn't be biggest possible security
breakdown amount to no more than the current publicly-
readable situation?
|
mcnally
|
|
response 124 of 147:
|
Apr 24 04:05 UTC 1998 |
Well, the problem is that the sendmail daemon has to do other
stuff that may require group permissions and it's only possible
to grant permissions for one group with the setgid flag.
Anyways, none of this discussion is going to change the fact that
.forward files must now be readable to sendmail and/or the local
delivery agents it uses, when they are running as other than root.
It's not clear to me that this implies that the files must be
world readable -- seems to me they could be group readable to
whatever group sendmail runs as but that's still not much of a
solution for most people as it's difficult to give away group
permissions on your files without priveleges (or is it only
difficult to chown things, not chgrp? IIRC, it's both -- originally
intended to stop people from foiling the quota system by changing
the ownership on files..)
|
