: Unfortunately, when you take setuid programs into account, it gets
: far less clear: Reasonable cases could be made for having the owner
: either the real or effective UID.
The case for effective seems quite clear to me, but
I can't see the case for real UID. What is it?
To Unsubscribe:
On Sun, 7 Nov 1999 10:15:42 -0500 (EST), Brian Fundakowski Feldman [EMAIL PROTECTED]
wrote:
The _REALLY_ obvious solution to this is to find the real path on exec()
and store the pointer in proc. How is this full of "overhead" and
"impractical"?
Finding _an_ absolute path on exec() is not too
In article [EMAIL PROTECTED] you write:
Brian Fundakowski Feldman wrote:
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
Err... I don't see the problem. The permissions of the hardlink will
be different, so the user might be able to see the "code", but won't
be able to run the suid (because the hardlink won't have the suid
bit set).
Suid bit is stored in the inode, not the directory entry, so it will
be set.
You can make hard links to
No, you cannot.
Yes you can - you just need to make sure the target directory is on
the same filesystem as the *original* file.
11:30:gonzo 9% cp /bin/sleep /tmp
11:30:gonzo 10% ls -l /tmp/sleep*
-r-xr-xr-x 1 dwmalone wheel 45224 Nov 7 11:30 /tmp/sleep
On Sun, 7 Nov 1999, Sean Eric Fagan wrote:
I don't, but what I like doesn't matter, it seems -- Warner knows everything.
So I'm sure he knows better than I do the overhead this will impose, and the
impracticality in a general system.
Unix really isn't set up to carry around 'official
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
Is this a real problem, or is it a "well don't protect suid
executables that way" problem? The permissions used in Linux's
/proc seem to be more conservative and seem to prevent this.
Yes. This is a real problem. One of the security team has had
patches since before FreeBSD CON. There are
In message [EMAIL PROTECTED]
Brian Fundakowski Feldman writes:
: 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
Brian Fundakowski Feldman wrote:
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
I'm sure this has been discussed before, but I couldn't find anything
doing a quick search of the lists.
I've thought about trying to add a /proc/nnn/fd to allow access to
a running processes file discriptors from other processes. The
fdescfs only supports access to a processes own file
David Malone wrote:
However, procfs currently allows people to do this with an executables
file. You can make hard links to and run /proc/nnn/file as it is
essentially another hard link to the executable file. This could
be a problem if you have suid executables protected by nonexecutable
12 matches
Mail list logo
