Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Oct 1999 09:39:26 -0500
From:      "Jeffrey J. Mountin" <jeff-ml@mountin.net>
To:        Daniel Tso <dan@tsolab.org>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: X won't start
Message-ID:  <3.0.3.32.19991012093926.009e3700@207.227.119.2>
In-Reply-To: <380339A0.93C4FE1D@tsolab.org>
References:  <Pine.BSF.4.05.9910121452001.64453-100000@bak.evertsen.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
At 09:37 AM 10/12/99 -0400, Daniel Tso wrote:
>> A link doesn't have (used) permissions. You must look to the permissions
>> of the file where the link points to.
>> 
>> Think about it. If the permissions of the link matter, everybody can make
>> a link to every program and give himself the permissions he/she likes.
>
>I've never understood this... why shouldn't a useful meaning be given to
>the permission modes of a symbolic link ?
>
>It could be treated like a directory -- indeed a symlink is kinda like a
>directory with only one entry: r could mean contents readable, w
>writable
>(alterable in situ, w permission in directory required for unlinking),
>and
>x for access (usable to dereference to target).
>
>Why shouldn't it be possible to prevent the public from using a symlink
>or
>seeing where it points to ?

What would be the point?
Either they can access what the link points to or they cannot.  With what
you are saying they would not be able to access via the symlink, yet could
do so directly making the permission on the symlink useless.  Could say
that's true now, but...

Rather simple rule:  Don't trust the permissions on a symlink.

Doubt symlink behaviour is going to change.


Jeff Mountin - jeff@mountin.net
Systems/Network Administrator
FreeBSD - the power to serve
'86 Yamaha MaxiumX (not FBSD powered)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19991012093926.009e3700>