Looking through the man pages
If you look at the man page for
excerpt - mount.cifs man page
mount.cifs which is what will be used to mount any shares listed in
/etc/fstab there is a note that mentions
This command may be used only by root, unless installed setuid, in
which case the noeexec and nosuid mount flags are enabled. When
installed as a setuid program, the program follows the conventions set
forth by the mount program for user mounts, with the added restriction
that users must be able to chdir() into the mountpoint prior to the
mount in order to be able to mount onto it.
Some samba client tools like smbclient(8) honour client-side
configuration parameters present in smb.conf. Unlike those client
tools, mount.cifs ignores smb.conf completely.
Given this I would expect it to honor the exec/noexec option if it's included in any mount attempts. Additionally looking at the
excerpt - mount.cifs usage
mount.cifs usage shows how that option would be used.
Less commonly used options:
Looking at the
excerpt from fstab man page
fstab man page explains the intended purpose for exec/noexec, but doesn't specify whether it's for all executables or just Unix ones.
exec / noexec
exec lets you execute binaries that are on that partition, whereas
noexec does not let you do that. noexec might be useful for a
partition that contains no binaries, like /var, or contains binaries
you do not want to execute on your system, or that cannot even be
executed on your system, as might be the case of a Windows partition.
Does exec/noexec make everything executable?
No the exec/noexec attribute simply gates the allowing of things that are marked as executable through their permissions bits, it doesn't effect the permissions directly.
What about Window's binaries?
However, the setting of exec/noexec has no control over Windows executables, only Unix executables that can also reside on these shares.
Also I'm not even sure how these would come into play if you're mounting a CIFS/Samba share through
/etc/fstab, when would a Windows OS even come into the mix in this scenario. Windows would/could mount this share itself directly and not even bother going through Linux.
Testing it out
Example from Unix
You can test this out using
mount.cifs directly via the command line like so. Assuming we had a file on the CIFS/Samba share as follows:
$ cat cmd.bash
$ chmod +x cmd.bash
Now we mount it like so, and try and run out script,
$ mount.cifs //server/cifsshare /path/to/cifsmnt -o user=joeuser,noexec
$ cd /path/to/cifsmnt
bash: ./cmd.bash: Permission denied
If we omit that option,
$ mount.cifs //server/cifsshare /path/to/cifsmnt -o user=joeuser
$ cd /path/to/cifsmnt
The only scenario I could conceive of here would be if I was using something like Virtualbox and I mounted a CIFS/Samba share inside of a directory that a Windows VM could then utilize.
When I tested this out, I was successfully able to run
.exe files through this mounting setup.
NOTE: I used the
\\vboxsrv share mechanism in Virtualbox to mount my home directory that's local on my system,
/home/saml. I then ran this command, mounting a CIFS/Samba share as a directory inside
$ mkdir /home/saml/cifsmnt
$ mount //server/cifsshare cifsmount -o user=joeuser,noexec
Doing the above would seem to indicate that exec/noexec has no baring over Windows' access to the files.