samba - Apr 2024 - howto achieve 'hide unreadable' for msdfs symlinks

hi,
on a samba domain member file server i'm using dfs root shares with 
multiple msdfs symlinks pointing to other shares (on the same server), 
which works fine. These linked shares have different access rights, 
therefore a user might have access to one linked share but not to another.

Is there any option to hide msdfs-symlinks to shares that a user cannot 
read? (the same as 'hide unreadable = yes' does for regular files)

Windows Server does support what i need, i'm using calls like this on 
windows: 'dfsutil property acl grant \\[server or namespace]\[the link] 
[group|user]:RXW protect'. That's also available in dfsmgmt.msc on a 
folder's properties.

I thought of the "hide unreadable" option, but it only works on files 
and directories, not symlinks (no surprise as symlinks are 777).
My last idea was vfs_xattr, but it does not help either. I tried to 
force xattr to symlinks via 'setfattr -h -n security.NTACL -v ... 
[file]' and hoped it would be evaluated for the symlink by samba - that 
doesn't seem to be the case.
As dfs-symlinks are resolved by the client, the linked share's rights 
could only be checked after resolving and accessing the symlinked share 
by the client. To hide the symlink from the client, the server would 
have to resolve the symlink or evaluate some ACL on the symlink before 
(as mentioned above).

I'd be grateful for ideas
thanks


-- 
M. Sc. Konrad Jacobi

Fraunhofer-Institut f?r Gro?strukturen in der Produktionstechnik IGP

Albert-Einstein-Stra?e 30 ? 18059 Rostock
Tel +49 381 49682-192
Fax +49 381 49682-12

konrad.jacobi at igp.fraunhofer.de
http://www.igp.fraunhofer.de

On Tue, Apr 16, 2024 at 04:21:29PM +0200, Konrad Jacobi via samba
wrote:
>As dfs-symlinks are resolved by the client, the linked share's rights 
>could only be checked after resolving and accessing the symlinked 
>share by the client. To hide the symlink from the client, the server 
>would have to resolve the symlink or evaluate some ACL on the symlink 
>before (as mentioned above).
>
>I'd be grateful for ideas
Me too :-). This is a difficult problem. Server resolving
the symlink would only be possible for DFS links that 
resolve to the local system. It's also probably a bad
idea. Having a local ACL is more interesting, but I'm
not sure if this is supported ?

On 16-04-2024 16:21, Konrad Jacobi via samba wrote:
> hi,
> on a samba domain member file server i'm using dfs root shares with 
> multiple msdfs symlinks pointing to other shares (on the same server), 
> which works fine. These linked shares have different access rights, 
> therefore a user might have access to one linked share but not to 
> another.
>
Another option is to specify the dfsroot "links" completely in
smb.conf,
like

[home]
 ??????? msdfs root = yes
 ??????? msdfs proxy = \fileserver\home
 ??????? comment = Home directory

Although? it does not support the hiding you want, at least it does not 
have requirements on the filesystem. Perhaps (@Jeremy) it is easier to 
implement some hiding mechanism on top of this configuration?

- Kees.

> Is there any option to hide msdfs-symlinks to shares that a user 
> cannot read? (the same as 'hide unreadable = yes' does for regular
files)
>
> Windows Server does support what i need, i'm using calls like this on 
> windows: 'dfsutil property acl grant \\[server or namespace]\[the 
> link] [group|user]:RXW protect'. That's also available in
dfsmgmt.msc
> on a folder's properties.
>
> I thought of the "hide unreadable" option, but it only works on
files
> and directories, not symlinks (no surprise as symlinks are 777).
> My last idea was vfs_xattr, but it does not help either. I tried to 
> force xattr to symlinks via 'setfattr -h -n security.NTACL -v ... 
> [file]' and hoped it would be evaluated for the symlink by samba - 
> that doesn't seem to be the case.
> As dfs-symlinks are resolved by the client, the linked share's rights 
> could only be checked after resolving and accessing the symlinked 
> share by the client. To hide the symlink from the client, the server 
> would have to resolve the symlink or evaluate some ACL on the symlink 
> before (as mentioned above).
>
> I'd be grateful for ideas
> thanks
>
>
>