: 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: se
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
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 /pr
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 p
> >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
11:3
> 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
On Sun, 7 Nov 1999, Sean Eric Fagan wrote:
> 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
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 virtua
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 th
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 pr
> 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 ar
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 discripto
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 nonexecutab
13 matches
Mail list logo
