On Thursday 02 January 2025 16:06:56 Jan Kara wrote: > On Fri 27-12-24 14:01:39, 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 > > Yes, this looks sensible to me. > > > 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). > > What manpage says can certainly be changed, just write to the manpage > maintainer. After all it is just documenting how the code behaves. I didn't > find anything in the standards that would forbid this behavior and we don't > even take standards too seriously ;). What matters is application behavior. > I would be a bit reluctant to change EPERM return code to EOPNOTSUPP for > all the filesystems (as much as I agree it would be more sensible error) as > I don't see a strong enough reason for risking that it might break some > application somewhere. But making Samba behave as above and documenting in > the manpage that EPERM means that particular problem for it sounds > certainly fine to me. > > Honza > -- > Jan Kara <jack@xxxxxxxx> > SUSE Labs, CR Ok, if it makes sense to use EOPNOTSUPP / EPERM / EACCES like I described above, then I can prepare changes for cifs.ko driver and also for Linux symlink manpage.
