[Replying to two messages here; I hope the quoting doesn't get too
confusing.]

>>> I've been watching this thread a little, and every time I see
>>> another suggestion made, I have to cringe... ;-(
>> Why?  [...]

> And I shiver as well...

> Why? Because the point of the POSIX standard is portable
> applications, and I have a hard time seeing how that goal is advanced
> by expansion of the symlink semantics beyond the point of industry
> consensus.

Whereas _I_ have a hard time seeing how you are ever going to move
forward if you stick to "industry consensus".

> If the industry segments represented in the POSIX working groups
> could only get consensus with the current minimal specification of
> symlink functionality, what purpose is served by insisting that
> NetBSD must extend the semantics in a way that would encourage
> non-portable application development?

I'm not insisting on anything.  I'm _suggesting_ things.  I've also
implemented one of the suggestions.

You seem to think of NetBSD as a least-common-denominator system,
something that does nothing but the minimum required by (in this case)
POSIX.  This is pointless, crippling to nearly everyone trying to use
it, and stifling to evolution.  I prefer to think of it as a testbed
for trying new ideas.  Ones that work can be adopted, and if they
really do work well and are useful will perhaps evolve into the
"industry consensus" that seems so precious to you.  Ones that don't
work can be discovered readily to not work and be dropped.

> With respect to the mode extensions, symlinks are only a short-cut to
> traversal of the "real" filesystem.  As such all access is already
> mediated by the modes of each path component, and adding mode
> interpretation to symlink evaluation contributes complexity and
> removes performance without a corresponding benefit.

The code complexity is entirely marginal; I have implemented the 0555
mode bits as I suggested, and the cost is six lines of added code for
the x bits, 28 lines _deleted_ to let real mode bits and owners show
through again, one line added for the r bits, and in my implementation,
seven lines changed so as to make relevant syscalls not follow terminal
links.  (If this were to go in for real, it might be better to add
parallel syscalls instead.)

> I categorically reject any change that would let symlink permissions
> override the access permissions of "hard" filesystem entities.  That
> is clearly outside the bounds of existing art in this area.

And NetBSD is supposed to do nothing that is not existing art?  I quite
disagree.

As for "override", none of my suggestions _override_ existing
permissions.  The proposed interpretation for the 0555 bits will cause
some previously successful operations to fail, but will not permit
anything that would have failed without those changes.  The set-id
symlink idea again would not override anything, but would potentially
cause a different set of bits to be used for permission checking of
part of the path walk.

> I do not claim the present design is perfect, only that it is
> sufficient.

Perhaps it is.  If all you want is a "sufficient" system, you won't be
interested in experimenting with my proposal.  But please don't try to
stifle those of us who _do_ want to advance the state of the art.

>>> It makes little sense to have any sort of protection based on [the
>>> owner and permission bits of a symlink]
>> I'm not sure why not; every other filesystem entity does something
>> with its ownership and permissions information.
> As I commented above, the effective pathname acheived by evaluating
> the symlink already has the owner/permissions protection.  Adding it
> to symlinks would introduce a source of conflicts in access
> protection.

So, what's wrong with this:
	Files already have owner/permissions protection; there's no
	need to complicate this and introduce conflicts by attaching
	significance to the ownership and permissions information on
	directories.

My suggestion does not lose you anything - chmod all your symlinks to
at least 0555 and you have the previous behavior.  And it does permit
some types of restricted access that were not possible before.  Whether
such things are actually useful is another question, and that's what I
was hoping to get ideas and/or opinions on when I posted my suggestion.

> The core functionality of symlinks is simply a string that gets
> pathname resolved before finishing the remainder of the original
> path.  Given that, all else is embellishment, and extraneous to the
> problem at hand.

Let's try these for size:

	The core functionality of directories is simply name->file
	mapping.  Given that, all else is embellishment...

	The core functionality of files is simply storing of data.
	Given that, all else is embellishment...

I hope you can see my point: we already have a lot more than "basic
functionality", and what more we have is extremely useful.  I'm
offering suggestions for adding "more" to symlinks.

>> This leaves us with the problem of that POSIX draft which specifies
>> that a bunch of syscalls follow terminal symlinks, thus producing
>> the four-way dilemma I covered in another message.
> If you like.  The real story is that the POSIX draft does what has
> not been done previously, and clearly specifies how a symlink gets
> interpreted by all interfaces that take pathnames.  It does this by
> establishing a blanket rule, and by declaring the cases where
> exceptions occur.  If additional exceptions are needed, by all means
> suggest them. I will be more than happy to forward them to the POSIX
> working group.

Needed?  Of course not.  Not even symlinks themselves are _needed_.

I really don't care enough about what POSIX does to bother.  I've
thrown out some suggestions, is all; an attempt to explore possible
meaning for some bits that were previously ignored.  POSIX is welcome
to do whatever it likes with these suggestions.  I think it would be
too early to mandate them; as far as I know only one system in the
entire world is running with them in place.  Naturally, I'd prefer that
it not mandate their absence, but if it does I'm certainly not going to
let that stop me - the change is to a marginal extent incompatible with
all other known current implementations of symlinks, but to my mind not
critically so.

[the other message now]

>> its ownership and permissions information.  My suggested
>> interpretation for the r and x bits seems fairly obvious; it's more
>> or less what they mean for directories.

> Huh?!?  If I am missing something here, lemme know.  Imagine this:

>> natasha:989> ls -al
>> total 749
>> drwxr-xr-x  5 weingart  staff     512 Aug  4 15:11 ./
>> drwxr-xr-x  9 weingart  staff    1024 Aug  5 17:23 ../
>> -rw-rw-rw-  2 weingart  staff     512 Jul 19 16:28 bar
>> lr--r--r--  1 weingart  staff      11 Aug  5 17:36 foo@ -> bar
(it'd be "3", not "11", but that's a nit.)
>> natasha:995> id
>> uid=1000(weingart) gid=20(staff) groups=20(staff)

> If the permissions are significant, then I could write to ./bar, but
> not to ./foo.

Right.  Indeed, you could not do anything with ./foo but
non-link-following things (eg, lstat(), readlink(), and whatever
variant of chown/chmod/etc doesn't follow terminal links).

> What is gonna prevent me from using ./bar?

Nothing at all.  Indeed, a mode 444 link is one of the less useful
permission combinations; the only use I've been able to think of for it
is to leave a pointer to something's new location in the old, but make
sure the old location does not work, so that things that use it get
updated.

> Also, if I don't have access to ./bar, then the perms on ./foo are
> not going to matter.

Not as far as link-following things go, true.

But now, if you had
	-rw-rw-rw-  2 weingart  staff     512 Jul 19 16:28 bar
	l--x--x--x  1 weingart  staff       3 Aug  5 17:36 foo@ -> bar
then you could use the name ./foo and you would be accessing bar, but
you couldn't tell that - you would be unable to readlink() the link,
even though you could follow it during a path walk.  (And ls would be
unable to show you the target of the link, so the above pseudo-output
would not actually occur.)  In this case, this isn't that significant.
But consider

	drwx--x--x  2 weingart  staff     512 Jul 19 16:28 bar
	lrwx--x--x  1 weingart  staff      18 Aug  5 17:36 foo@ -> bar/blee/blop/file

Now, anyone has access to that file by the name "foo" (assuming
bar/blee and bar/blee/blop are at least --x), but they can't find out
what the "real" name of the file is.  If the stuff under "bar" is
something you don't want to even reveal directory names in, this could
be useful.

And if you implement setuid symlinks,

	drwx------  2 weingart  staff     512 Jul 19 16:28 bar
	lrws--x--x  1 weingart  staff      18 Aug  5 17:36 foo@ -> bar/blee/blop/file

Now, anyone can access bar/blee/blop/file by the name foo.  But they
can't readlink() the link to find out where it points, and moreover,
even if they knew, they couldn't use that path directly.  You have thus
granted access to a very small portion of an otherwise inaccessible
tree in a controlled way.

Mind you, none of this affects what people may or may not do with the
file once they get it.  The permissions on the target itself will, as
always, control that.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu