Bug 993 - Errors when creating symlinks
Errors when creating symlinks
Status: RESOLVED FIXED
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.4
Other Linux
: P3 normal
: ---
Assigned To: Steve French
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-21 22:57 UTC by Roman Dubtsov
Modified: 2005-03-24 14:09 UTC (History)
2 users (show)

See Also:


Attachments
patch to allow creation of symlinks (1.51 KB, patch)
2004-02-04 10:46 UTC, Roman Dubtsov
no flags Details
patch to smbfs and cifs implementations to allow creation of symlinks (2.21 KB, patch)
2004-02-04 10:52 UTC, Roman Dubtsov
no flags Details
The correct patch (1.62 KB, patch)
2004-03-04 10:24 UTC, Roman Dubtsov
no flags Details
updated cifs mount helper (28.85 KB, text/x-csrc)
2005-03-18 23:08 UTC, Steve French
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Dubtsov 2004-01-21 22:57:44 UTC
Let some share with rw access and unix extensions = on be mounted on /mnt/foo.
And inside the share we have dir "bar" (/mnt/foo/bar), and a file "foobar" 
(/mnt/foo/foobar). 

One wants to create symlink to "foobar" inside "bar" (ln -s ../foobar foobar), 
but what he gets is a "File not found" message (or, if he is root "Permission 
denied"). 

Though executing "ln -s /foobar foobar" succeeds and creates symlink to the 
file in root dir (/foobar), not relative to mountpoint.

Thus, ensure_link_is_save fails to do it's job properly or wrong arguments are 
passed to it (or the directory change to the "bar" is not recorded properly in 
connection stats struct).
Comment 1 Roman Dubtsov 2004-01-21 23:44:53 UTC
Oops. ln -s /foobar foobar creates a symlink in the _same_ dir (i.e to foobar).
Comment 2 Gerald (Jerry) Carter 2004-01-22 04:20:23 UTC
is this with the cifsvfs ?  smbfs doesn't support unix 
extensions anyways.
Comment 3 Roman Dubtsov 2004-01-22 08:07:15 UTC
Yes, this applies to cifs vfs too. But symptoms are the same. Besides, 
creation of hard links works fine (though, cifs_hardlink system call takes 
dentry-s as params...). 
Comment 4 Roman Dubtsov 2004-02-04 10:46:33 UTC
Created attachment 379 [details]
patch to allow creation of symlinks

This is a patch against samba 3.0.1 with smbclient patched. It changes how smbd
handles SMB_SET_FILE_UNIX_LINK, introducing new function make_link_relative. It
relies on smbclient's way of passing data to server when creating symlinks.
Comment 5 Roman Dubtsov 2004-02-04 10:52:02 UTC
Created attachment 380 [details]
patch to smbfs and cifs implementations to allow creation of symlinks

This patch is against vanilla linux-2.6.2-rc3. It makes cifs/smbfs to pass
symlink  destination relative to the directory where symlink is created. This
makes the way how arguments are passed to server consistent with smbclient's
way.
Comment 6 Gerald (Jerry) Carter 2004-03-04 08:09:42 UTC
Steve & Jeremy,  could you look at the smbclient / cifsvfs patches 
and do whatever you think is best ?  Thanks.

And let me know once your done so we can close this one out.
Comment 7 Roman Dubtsov 2004-03-04 10:23:11 UTC
I'm sorry for late comment: all the patches proposed by me are broken :( the 
correct (as I hope so) patch for samba is in the next attachment. 
 
Comment 8 Roman Dubtsov 2004-03-04 10:24:02 UTC
Created attachment 425 [details]
The correct patch
Comment 9 Steve French 2004-03-04 11:02:21 UTC
I don't object to the principal here but it could be controversial (since the 
NFS precedent and Unix precedent in general is to have the server treat the 
symlink data as opaque).   Figuring out whether there is a security exposure in 
these symlinks being followed on the server when Samba is serving Windows (or 
non-Unix extensions aware clients)

My main worry is that converting an absolute to a relative path may not make 
much sense in the client's name space (although it could on the servers) and 
could intentionally end up crossing filesystems on the client when the client's 
is the one following the link (ie the case of Unix extensions or NFS client)

Another possibility is the "client only" symlink idea that Apple is testing - 
which relies on a "magic file size" (1065 bytes I think) as a hint to the 
client to link in the data for symlink info.   I personally prefer that we 
handle "client only" symlinks via the reparse flag with the reparse data 
containing the symlink (rather than relying on overloading file data for normal 
files of a certain size to optionally include symlinks). 
Comment 10 Jeremy Allison 2004-03-04 11:04:19 UTC
Unfortunately this patch is now not applicable with the latest changes
to pathname processing in the SAMBA_3_0 CVS tree. I also tested that 
symlinks work (and hardlinks also) when coding up the new pathname
processing. My guess is that this will be fixed in the latest CVS
as I now process ../ within Samba.

Jeremy.
Comment 11 Gerald (Jerry) Carter 2004-03-04 11:55:08 UTC
Steve,  Since jra thinks the smbclient patch is 
obselete now, I'm moving this bug to cifsvfs
so you can do as you see fit.
Comment 12 Steve French 2005-02-10 14:39:47 UTC
I will fix this.
Comment 13 Steve French 2005-02-14 14:09:51 UTC
sorry - comment above was posted to the wrong defect - I doubt that the patches
are relevant now.
Comment 14 Steve French 2005-03-18 23:08:08 UTC
Created attachment 1051 [details]
updated cifs mount helper

gcc mount.cifs.c -o mount.cifs

mount.cifs goes in /sbin typically (backup your original mount.cifs)
Comment 15 Steve French 2005-03-18 23:10:25 UTC
Comment on attachment 1051 [details]
updated cifs mount helper

This mount.cifs.c goes with a different defect (bugzilla got confused).
Comment 16 Steve French 2005-03-24 14:09:05 UTC
Current Samba and cifs vfs handle these.  If there is still a problem or
enhancement to symlinks you would like to see.  Please reopen with the
additional data or create a new bug report.