[1719] in linux-security and linux-alert archive
[linux-security] Re: Re: message rejected: Re: Re: Towards a solution of tmp-file problems.
daemon@ATHENA.MIT.EDU (Pavel Kankovsky)
Fri Mar 13 13:05:21 1998
Date: Fri, 13 Mar 1998 11:22:39 +0100 (MET)
From: Pavel Kankovsky <peak@kerberos.troja.mff.cuni.cz>
Reply-To: peak@kerberos.troja.mff.cuni.cz
To: linux-security@redhat.com
In-Reply-To: <199803121209.XAA17164@gidora.zeta.org.au>
Resent-From: linux-security@redhat.com
On Thu, 12 Mar 1998, Nick Andrew wrote:
> The file descriptor to which I am referring is _not_ the file descriptor
> which is the contents of "/tmp/ccxxxxx.i". It is a file descriptor which
> enables a holding process to open "/tmp/ccxxxxx.i" without any possibility
> of another process (which does not hold the file descriptor) opening the
> same file because ... the namespace which contains the file(s) is
> inaccessible to processes which do not hold the file descriptor.
Currently, most "privilege boundaries" in unix are determined by uids and
gids. I think it is the complete waste of effort to invent something
with finer granularity for one specific purpose (/tmp).
> Its behaviour is more like a capability than a file. You might wonder why
Yes, capabilities are nice, and solve many security probs in an elegant
way... Anyone willing to make a hybrid of Linux and KeyKOS? :)
--Pavel Kankovsky aka Peak [ Boycott Microsoft -- http://www.vcnet.com/bms ]
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
