Peter J. Braam writes:
>
> Let's just take one step back.
>
> Al has successfully pointed out that one should not expect too much in
> terms of security improvements for my hardlink suggestion.
>
> Al additionally gave two reasons, totally unrelated to the security
> issues, not to implement the link semantics as I suggested:
>
> - a very valid, but also dogmatic "it's not Unix"
> - "don't put policy in the kernel"
>
> I think I accept his points, and it's probably not a good idea to put it
> in the VFS.
>
> Coda and AFS have directory ACLs and no file acl's. They could do cross
> directory hardlinks safely with my proposed change. So we can make this
> Coda policy.
>
> Before doing so, I'd still like to ask once more: is there a problem with
> this, ie. with changing LINK for Coda, ie. are there known programs that
> can currently work with Coda that will break because we will change the
> semantics of LINK.
>
> It seems very unlikely since every operation that was previously
> possible remains possible. Yet, since there are a lot of smart
> people listening here, I'd like to ask it again before we stop the
> discussion.
I dunno about programmes breaking, but I can definately say that
making hardlinks to files in other directories (not owned by the
linking user) is a handy feature. Sure, in some (hostile) environments
you might want to restrict hard links, but in other environments it's
really handy. Symlinks aren't always the answer.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
