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 pathname of the executable being stored as
> >> a virtual symlink in procfs as "file" would solve these security
> >> problems?
> >Mmmmm... I like that...
>
> 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 pathnames,' due to the
> existence of symlinks and other fun stuff. Other systems are set up for this
Linux is now one of them..
the file descriptor now (I was told) leads to a name cache entry, which is
the name under which it was openned. THat in turn has a pointer to teh
directory that it was in...etc.
> -- my favourite was EMBOS, by ELXSI -- and there are some _really_ nifty
> things you can do, if you have it. (Watchdogs and program-based-access-lists
> are my two favourite, the latter allowing you to get rid of SUID/SGID in many
> cases. There is a paper available on implementing watchdogs under unix
> [4.2bsd, I believe] that discusses some of this. If you're willing to cover
> 60-80% of the cases, instead of 95-100%, it's considerably easier.)
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
