TL;DR;
Which errno code should network fs driver returns on create symlink
failure to userspace application for these cases?
* creating new symlink is not supported by fs driver mount options
* creating new symlink is not supported by remote server software
* creating new symlink is not supported by remote server storage
* creating new symlink is not permitted for user due to missing
privilege/capability (indicated by remote server)
* access to the directory was denied due to ACL/mode (on remote)
Hello,
I discussed with Steve that current error codes from symlink() syscall
propagated to userspace on mounted SMB share are in most cases
misleading for end user who is trying to create a new symlink via ln -s
command.
Linux SMB client (cifs.ko) can see different kind of errors when it is
trying to create a symlink on SMB server. I know at least about these
errors which can happen:
1 For the current mount parameters, the Linux SMB client does not
implement creating a new symlink yet and server supports symlinks.
This applies for example for SMB1 dialect against Windows server, when
Linux SMB client is already able to query existing symlinks via
readlink() syscall (just not able to create new one).
2 For the current mount parameters, the SMB server does not support
symlink operations at all. But it can support it when using other
mount parameters. This applies for example for older Samba server with
SMB2+ dialect (when older version supported symlinks only over SMB1).
3 The SMB server for the mounted share does not support symlink
operations at all. For example server supports symlinks, but mounted
share is on FAT32 on which symlinks cannot be stored.
4 The user who is logged to SMB server does not have a privilege to
create a new symlink at all. But server and also share supports
symlinks without any problem. Just this user is less privileged,
and no ACL/mode can help.
5 The user does not have access right to create a new object (file,
directory, symlink, etc...) in the specified directory. For example
"chmod -w" can cause this.
Linux SMB client should have all information via different SMB error
codes to distinguish between all these 5 situations.
On Windows servers for creating a new symlink is required that user has
SeCreateSymbolicLinkPrivilege. This privilege is by default enabled only
for Administrators, so by default ordinary users cannot create symlinks
due to security restrictions. On the other hand, querying symlink path
is allowed for any user (who has access to that symlink fs object).
Therefore it is important for user who is calling 'ln -s' command on SMB
share mounted on Linux to distinguish between 4 and 5 on failure. If
user needs to just add "write-directory" permission (chmod +w) or asking
AD admin for adding SeCreateSymbolicLinkPrivilege into Group Policy.
I would like to open a discussion on fsdevel list, what errno codes from
symlink() syscall should be reported to userspace for particular
situations 1 - 5?
Situation 5 should be classic EACCES. I think this should be clear.
Situation 4 start to be complicated. Windows "privilege" is basically
same as Linux "capability", it is bound to the process and in normal
situation it is set by login manager. Just Linux does not have
equivalent capability for allowing creating new symlink. But generally
Linux for missing permission which is granted by capability (e.g. for
ioperm() via CAP_SYS_RAWIO) is in lot of cases returned errno EPERM.
So I thought that EPERM is a good errno candidate for situation 4, until
I figured out that "symlink(2)" manapage has documented that EPERM has
completely different meaning:
EPERM The filesystem containing linkpath does not support the
creation of symbolic links.
And I do not understand why. I have tried to call 'ln -s' on FAT32 and
it really showed me: "Operation not permitted" even under root. For user
this error message sounds like it needs to be admin / root. It is very
misleading.
At least it looks like that EPERM cannot be used for this situation.
And so it is not so easy to figure out what error codes should be
correctly returned to userspace.
Pali
