On Sat, 6 Nov 1999, Warner Losh wrote:
> There are ways that the user can see the code to execute it, but not
> read it normally. procfs breaches this inability to read the file.
> Also, there are many related problems which make a proper fix for this
> that is more complicated than removing /proc/xxx/file nearly
> impossible. "Proper" here means "A fix which will prevent the
> disclosure of a file to unauthorized people which would normally not
> be able to read the file."
>
> I'm convinced that it would be hard to codify all the security checks
> needed to access the file originally into a single number which would
> allow people that could read the original file to read /proc/xxx/file
> and disallow people who couldn't read the file to also be disallowed
> from reading /proc/xxx/file.
It sounds to me that what you really want are the semantics of a
symbolic link and not the semantics of a hard link. Is it just me,
or does it seem as if the pathname of the executable being stored as
a virtual symlink in procfs as "file" would solve these security
problems?
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED] `------------------------------'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
