Message-ID: <20241227130139.dplqu5jlli57hhhm@pali>
Date: Fri, 27 Dec 2024 14:01:39 +0100
From: Pali Rohár <pali@...nel.org>
To: linux-fsdevel@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc: Steve French <sfrench@...ba.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>
Subject: Re: Errno codes from symlink() syscall

On Tuesday 24 December 2024 17:05:35 Pali Rohár wrote:
> 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

I was thinking more about it and the reasonable solution could be to use
following errno codes for these situations:

 EOPNOTSUPP - server or client does not support symlink operation
 EPERM - user does not have privilege / capability to create new symlink
 EACCES - user does not have (ACL) permission to create new symlink

But in this case it would be needed to extend symlink(2) manpage. It is
feasible? Or the meaning of EPERM is written in the stone, it means that
operation is not supported, and it cannot be changed?

For me it sounds a bug if EPERM means "not supported", and also "ln -s"
tool does not understand this EPERM error as it shows human readable
message "Operation not permitted" instead of "Operation not supported"
(which is the correct one in this situation).

Powered by blists - more mailing lists