Bug 566 - Exporting symlink not possible
Summary: Exporting symlink not possible
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Local drive redirection (show other bugs)
Version: 1.3.0
Hardware: PC Linux
: P2 Enhancement
Target Milestone: MediumPrio
Assignee: Peter Åstrand
Depends on: 5196
  Show dependency treegraph
Reported: 2004-05-12 14:21 CEST by Peter Åstrand
Modified: 2014-06-25 14:38 CEST (History)
0 users

See Also:
Acceptance Criteria:


Description Peter Åstrand cendio 2004-05-12 14:21:48 CEST
unfsd does not support exporting a directory which is a symbolic link to another
directory. For example, on Neoware terminals, /tmp is a symlink to /var/tmp. In
this case, the user must export /var/tmp rather than /tmp. 

We should fix this, or at least document it.
Comment 1 Peter Åstrand cendio 2005-03-24 14:54:29 CET
This problem is more severe than I first realized. unfsd currently exports the
symlinks themselves; not the object it points to. This is a major problem with
VXL Itona terminals: USB sticks are mounted on, say,
/tmp/.diskmount/USB/Cruzer_Micro. A symbolic link called
/tmp/browse/usb_Cruzer_Micro points to this directory. With this setup, it's
impossible to export the USB drive with ThinLinc:

1) If you export /tmp/browse, then the symlink itself will be exported, and the
path /tmp/.diskmount/USB/Cruzer_Micro doesn't exist on the terminal server...

2) You cannot export /tmp/browse/usb_Cruzer_Micro, since it's a symlink. And
even if you could, it would make no sense, since different USB sticks have
different names. 

3) You can export /tmp/.diskmount/USB, but the directory Cruzer_Micro is not
visible until you try to access it (as automounters usually works). Thus, the
user would not be able to browse to the USB stick. 

4) You can export /tmp/.diskmount/USB/Cruzer_Micro, but then, this export will
only work with USB devices that identifies as Cruzer_Micro. 

If I remember correctly, eLux solves the problem by defining the mountpoints
"usb0", "usb1" etc. We should re-check this. 

Sigh. I have no idea to solve this properly. Of course, it would be possible to
change unfsd so that it interprets symlinks locally, but sometimes, this is not
what you want. 
Comment 2 Peter Åstrand cendio 2005-03-29 10:27:26 CEST
One idea could be to have a unfsd "server-wide" configuration parameter that
controls if symlinks should be resolved locally or not. We could take a look at
Sambas options for some inspiration. 
Comment 3 Peter Åstrand cendio 2005-05-03 11:41:50 CEST
Perhaps to 1.4.1. 
Comment 4 Peter Åstrand cendio 2005-06-09 13:40:17 CEST
I think we should implement what's suggested in comment 2: A "server" wide
configuration parameter. It should be an option to unfsd, and also an option in
the tlclient GUI. 
Comment 5 Peter Åstrand cendio 2006-06-16 11:25:48 CEST
One problem with a simple boolean "follow symlinks" option is that it makes it
impossible to use symlinks on, say, removable media. For example, assume that
you inserts a USB stick in a VXL terminal with a symlink "foo" that points to
"bar". If unfsd is configured to always follow symlinks locally, it would
present both "foo" and "bar" as normal files, which might confuse users or even
break some applications. 

For VXL, I think that what we want is to export /tmp/browse, and follow symlinks
but only in this directory - not deeper. That would allow usage of symlinks of
mounted drives. This option should still be configurable, though, but I'm not so
sure anymore that it should be global. 

Allow following symlinks on the mountpoint itself is probably always a good
idea. I don't see why it shouldn't be hardcoded. 
Comment 6 Peter Åstrand cendio 2007-07-09 11:37:30 CEST
When solving bug 2337, I had to manually resolve the chain of symlinks. /usb/usb-drive eventually ended up as /tmp/config/user_mount/usb/.autofs/usb-drive.auto. Besides being clumsy and ugly, there's a risk that this path changes in the future. It would be much nicer if we could use the documented paths. 
Comment 7 Peter Åstrand cendio 2014-06-25 14:38:08 CEST
When solving this bug, the interim solution added on bug 5196 should be removed.

Note You need to log in before you can comment on or make changes to this bug.