Date: Tue, 12 Oct 1999 12:04:51 -0400 From: Dan <dan@tsolab.org> To: "Jeffrey J. Mountin" <jeff-ml@mountin.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: X won't start Message-ID: <38035C23.93CBAA39@tsolab.org> References: <Pine.BSF.4.05.9910121452001.64453-100000@bak.evertsen.nl> <3.0.3.32.19991012093926.009e3700@207.227.119.2>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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. Not an issue of trust, but of hardcoded semantics. Yes, refining the semantics of symlink access modes is not going to be a big win, but it would still have some possible uses -- again analogous to modes of directories, which also has always been a bit squirrelly (sp?) (e.g. what is the point of r but not x for a directory ?) A similar "feature" is the use of mode 711 for a directory, in which people who know a file's name can get at it, but the directory cannot be read. Not a particularly good security mechanism, but it is still a commonly used feature. For a user with a shell, from a security standpoint, yes symlink modes don't make too much sense. But I can imagine some applications programs that may wish to play with symlinks in ways that their modes might be helpful. The Apache webserver is one example of a program offering a relatively closed environment, which permits the use of symlinks to reach beyond its "root" directory space. On a slightly different vein... several years ago, Pyramid added the notion of "conditional" symlinks, where a symlink would return a different target depending on the state of certain user variables (it was used to implement a System V vs a BSD user environment). I've always thought that symlinks could be extended along these lines would be incredibly useful. It could implement a whole little script language, returning any number of targets depending on what happens within the symlink script. For example, depending on uid, time of day, whether a remote host is down (providing backup target), whether a filesystem is full, etc... 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?38035C23.93CBAA39>