Message-ID: <20250104-altglas-pedal-9576abc7b63c@brauner>
Date: Sat, 4 Jan 2025 09:46:26 +0100
From: Christian Brauner <brauner@...nel.org>
To: Pali Rohár <pali@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-cifs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Steve French <sfrench@...ba.org>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>
Subject: Re: Errno codes from symlink() syscall

On Fri, Dec 27, 2024 at 02:01:39PM +0100, Pali Rohár wrote:
> 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

This sounds reasonable and should be doable.

Powered by blists - more mailing lists