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.
