msdfs on 3.0.25b - hide unreadable on DFS links

[Jan Martin]

(This is the third - and last - one of our recent problems regarding the
visibility of msdfs contents.)


In Samba 3.0.24, bug 3319 was fixed ... in a way that one of our most
important Samba features vanished.

The situation didn't change by now (SAMBA_3_0_25, this morning)

We are running a central Samba service as a dispatcher for many file
services behind it, relying on its ability to hide all entries that the
user can't see anyway.

When we installed it some time ago, it was tricky to find out how to do
it (we had to understand the source), but we succeeded.

The fix for bug 3319 just excluded all DFS links from hiding. Obviously,
the involved people didn't see a real use (or possibility) of
hiding/unhiding for DFS links.

But for us, it's essential. The hide unreadable feature (even for DFS
links) was the original reason to set up this service on Samba instead
of Windows.

Of course, just reverting the bugfix would result in the old behaviour:
Without further intervention, DFS links are hidden, so most users can't
use them. It would be sufficient for our installation (we are running
the server like that right now as a temporary workaround), but it would
be a setback for the community.

So we need another solution.

The most obvious solution would be to create a share parameter called
"never hide msdfs links" with default "yes" that controls the behaviour.

For other solutions (I think that they are worth a look), I must go a
little bit more into detail.

We are hiding/unhiding DFS links by giving the msdfs:... symlink a valid
target, which must be a directory. After that, we give the proper rights
to the symlink target.

Example:
lrwxrwxrwx 1 root bin         28 Aug  7 17:57 aLink ->
msdfs:someOtherServer\aShare
drwxr-x--- 2 root someGroup 4096 Aug  7 17:54
msdfs:someOtherServer\aShare

In this situation (with hide unreadable enabled and without the bug 3319
fix), only members of the Unix group someGroup can see the msdfslink
aShare.
(In practice, we don't do it manually. We are runnning a script that is
collecting the access rights from all places, converts them to POSIX
access control lists, creates the symlinks with their targets and
applies the access control lists)

Now the second option for our solution becomes clear: Samba may unhide
dangling msdfs:* symlinks only, while respecting the access control of
valid symlink targets, if they exist. This would result in an automatic
switch between the old behaviour (good for users like us) an the current
behaviour (good for new users who wonder why their DFS links don't show
up).

Going a step further (solution no. 3), Samba could automatically try to
create valid targets for dangling links on first access (which should
normally be a findfirst/findnext or similar) using a default uid, gid
and mode (such as Samba's uid/gid with mode 0755).

This would make it easy for unexperienced users to apply access rights.
They can just use their tools (chgrp, chmod, ...) on the symlink, which
would be followed. Of course, security is an issue here. I hope that the
'msdfs:' prefix, together with the removal of all \..\ path elements
(all slash/backslash combinations) and typical dangerous characters
(quotes, semicolon, line feed, ...) is sufficient to prevent misuse.

Just for completeness, we should consider a forth solution: allowing
plain files or directories as msdfs links (instead of symlinks). This
would mean to reinvent all details of the ingenious old msdfs:* symlink
syntax, while getting a chance to make msdfs really easy for beginners
(not everyone can handle these links in a shell without strictly
following a manual). We thought about this for some time and came to the
conclusion that it would be a long discussion and no real fun to write
the code.

Before starting to write a patch (we could try it, at least for solution
no. 2), it's time to ask the Samba community.

What do you think about our problem and the solutions mentioned above?

... or about other solutions?

Many thanks for your patience to everyone who came to this point.



Jan Martin