Warning: Failed mail to VMS host
mail-support%cernvax.cern.ch at pucc.princeton.edu
mail-support%cernvax.cern.ch at pucc.princeton.edu
Sat Dec 15 08:39:57 AEST 1990
Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN at CERNVAX.BITNET> could
not be delivered.
The error message was:
Deferred: %MAIL-E-OPENOUT, error openning as output
This message is equivalent to the DECnet-VAX error message:
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded
The reason why your message could not be delivered is caused by the fact that
your correspondants account has ran out of diskquota. Please contact your
correspondant (by phone or otherwise) and tell him about this problem.
====== The start of Your original message ======
UNIX-WIZARDS Digest Fri, 14 Dec 1990 V11#061
Today's Topics:
Re: non-superuser chown(2)s considered harmful
Re: Multics bloat??? Are you sure???
Re: Shared memory (shm) - a safe way to pick ids?
Has anyone hacked ftpd to keep a log of outgoing files?
Re: Has anyone hacked ftpd to keep a log of outgoing files?
What does sync() _really_ do?
Re: PROCESS MIGRATION
Re: Password and gecos
Re: Complex security mechanism is unsecure
Re: What do I do wrong?
Re: fun things mapped into user space
Programmatic interface to dynamic linker
Re: How to get past end of cpio archive on tape
Re: How do you find the symbolic links to files.
Re: Unix files should have both real and effective ids for files too
sdbm is available.
Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6
Re: Interfaces for accessing kernel memory
Re: Preventing date rollback
Re: PROCESS MIGRATION IN UNIX
Re: Looking for code
-----------------------------------------------------------------
From: Leslie Mikesell <les at chinet.chi.il.us>
Subject: Re: non-superuser chown(2)s considered harmful
Keywords: chown, mail
Date: 11 Dec 90 20:36:32 GMT
To: unix-wizards at sem.brl.mil
In article <1990Dec11.005644.20688 at cbnewsk.att.com> hansen at pegasus.att.com (Tony
L. Hansen) writes:
>< Exactly. This is why several people have been arguing for chown() to
>< work between current and effective uids. Does chown() have any other
>< reasonable use?
>
>The mail(1) command uses chown(2) and set-gid to give a secure mail system. I
>feel that other methods are fraught with potential security holes.
>
> Tony Hansen
> att!pegasus!hansen, attmail!tony
> hansen at pegasus.att.com
Are you talking about the same SysV /bin/mail that I have (AT&T SysVr3)
that uses the environment variable LOGNAME to decide who you are
and allows you to forward your mail with the command:
mail -F new_address
If you are, try:
MAIL=/usr/mail/you LOGNAME=you mail -F me
(replace "you" with someone else on the system who happens to have an
empty mailbox, and "me" with your login name)
Then tell me if you would still describe the system as secure.
Les Mikesell
les at chinet.chi.il.us
-----------------------------
From: Rik Harris <edp367s at monu6.cc.monash.edu.au>
Subject: Re: non-superuser chown(2)s considered harmful
Date: 13 Dec 90 15:51:48 GMT
To: unix-wizards at sem.brl.mil
dag at fciva.FRANKLIN.COM (Daniel A. Graifer) writes:
>In article <1990Dec11.101909.10851 at kithrup.COM> sef at kithrup.COM (Sean Eric
Fagan) writes:
>>
>>I prefer the control you get from a proper implementation of ACL's. See
>>Elxsi's EMBOS for an example. (Normal ACL's, an extension of Unix's rwx
>>philosophy, with users and groups; passwords for files [I forget whether
>>different users could have different passwords; I think so], and the ability
>>to specify that a file can only be accessed using a program from a given
>>program list [*neat*; I couldn't think of a normal use for SUID programs
>>under embos given that!].)
[guardfile stuff deleted]
>This is off the subject of unix internals, but Burroughs had a lot of the
>elements in place for an 'object-oriented' file system clear back in the
>early '70s. If we're going to talk about where we'd like unix to go, there
>are previous successful experiances to guide us.
Eeek! The reason I love unix so much is because it's simple. Start
adding security `features' like this, and things start getting
complex. ACL's are nice, but generally groups are sufficient (given a
good group managment system, though).
Rik.
--
Rik Harris - edp367s at monu6.cc.monash.edu.au | Build a system that
new address! rik at sola.fcit.monash.edu.au | even a fool can use,
Faculty of Computing and Information Technology, | and only a fool will
Monash University, Caulfield Campus, Australia | want to use it.
More information about the Comp.unix.internals
mailing list