On Ubuntu, if you use (external) drives formatted as exFAT or NTFS, i.e. not ext4 or something made for the UNIX world, you may end up with a situation where all files are executable.

This is because the file systems may have other concepts of permissions, or none at all. And it is to faciliate sharing between multiple computers. That makes sense.

Usually, you can even adjust this behavior in the mount options. But with the default options, the drives are often auto-mounted with the behavior described above.

Could you consider this a security risk? Especially if it comes to non-technical users, who will only ever use the default mount options (e.g. your grandma whom you switched to Ubuntu).

You could probably say it very much depends on the contents of the drive. But why introduce the risk?

  • 3
    Execution restrictions are not a security feature in general.
    – forest
    Commented Sep 27, 2018 at 1:01
  • 1
    @forest Well, if it’s not a security feature, what is it? It’s grouped within the set of “permissions”, at least. Semantically, this suggests that it’s related to security. So would you say that “whatever you can read, you can execute”, and “you can just chmod it anyway”? So the executable bit is only for convenience to facilitate execution with fewer clicks? I would say it’s a GUI-wise security feature, just as a confirmation dialog is. Unexperienced users (or really, everyone) may run malicious code when double-clicking a file from a mail attachment – but only if the executable bit is set.
    – caw
    Commented Sep 27, 2018 at 6:51
  • @forest There are different aspects of security. Hard internal and technical guarantees in the kernel are one aspect. Preventing the average user from doing something silly via the GUI is another aspect, wouldn’t you agree?
    – caw
    Commented Sep 28, 2018 at 10:50
  • 1
    The noexec flag was created long before GUI security was ever considered. While it may have some limited security benefits (e.g. breaking some automated bots that try to download and execute a file in /tmp), it is not designed for security. See also this answer as linked above.
    – forest
    Commented Sep 28, 2018 at 10:53

2 Answers 2


The default is to auto mount the drive in read/write mode. There are no other evaluations or alterations with regard to executability. Nothing is going to auto-run if that's your concern.

Can someone execute a file from a mounted drive, certainly they can. That's the behavior most people want.

There are forensic builds that are configured to mount Read-Only in order to protect against modifications of the mounted device, but it's still possible to execute a file if you choose to do so.

No I don't consider this to be a security risk. Yes, someone can do foolish things within the constraints of their user permissions.


Ah, I see!

FAT16 and FAT32 do not have this behavior. ExFAT and NTFS do indeed mount with 'x' enabled. I had never noticed this before.

Yes this does strike me as potentially dangerous. I'll have to research this as to why it's ocurring.


Good answer here:


  • Thank you! I wasn’t under the impression that things could “auto-run” from a drive. But what do you think about a normal, non-technical, unexperienced user double-clicking an unknown (untrusted) file and this resulting in either (a) the file opening, if the executable bit is not set, or (b) the file being executed, if the executable bit is set? Isn’t that a security feature with modern computer usage and non-expert users in mind?
    – caw
    Commented Sep 27, 2018 at 7:03
  • 1
    Would you want the system to automatically change your file permissions to remove executable capability everytime you plugged in a drive? Potentially thousands of files? Should it change them back when it unmounts? Should it create a virtual mount without 'x'? Would it maintain a virtual ability to change 'x' as needed? Would you want to have to redo this everytime you plugged in? Many alternative implementations are possible, but consider the user ramifications. I'm annoyed that Windows 10 writes a file to my thumb drives when I plug one in. Commented Sep 27, 2018 at 21:56
  • Right now, the system automatically changes my file permissions to add executable capability every time I plug in a drive. So I don’t think that’s necessarily better. In both cases, the permissions are changed. You cannot avoid changing them when the file system cannot store them. Perhaps it would be better to err on the safe side, though. Or ask. Or have a setting.
    – caw
    Commented Sep 28, 2018 at 8:20

This started as a response to your comment here but made more sense as a full answer.

Right now, the system automatically changes my file permissions to add executable capability every time I plug in a drive.

No it doesn't! The files are already executable, in the sense that this is the default behavior of files on those file systems. The system is not changing any file permissions because the *FAT file systems literally don't support an "execute" permission. NTFS does, but it's set by default on all files, and in any case the usual behavior of the NTFS driver on Linux is to ignore file ACLs since they pertain to users who do not exist on the system. I don't know what would happen if you used Windows to remove (or even deny) Execute permission to "All users" (the Windows equivalent of "world") and then mounted the relevant device on Linux, but my guess is that the Linux NTFS driver would ignore the lack/forbidding of execute permission the same way it ignores other NTFS ACLs. In any case, it certainly wouldn't automatically change them; at worst it would ignore them, the same way Windows (by default) ignores the execute (traverse) permission on directories1.

Could you consider this a security risk?

No, not really. Security is a matter of preventing unauthorized behavior, and there isn't any of that here. Obviously the permissions themselves are unenforceable - anybody with Administrator/root access could override them in multiple ways, and are the ultimate arbiter of what is or isn't authorized - so executing a file is always authorized on a machine you control. If an admin doesn't want a non-root user to execute files from removable storage, or outside a specifically allowed list, that's up to the admin to configure for the relevant user[s]/machine[s] (e.g. by changing the automatic mount permissions to noexec). File permissions are only a relevant concept within a closed system like a single machine, which removable storage generally does not remain within anyhow.

The user might sometimes benefit from a "hey, did you mean to run that?" confirmation pop-up when launching an executable from a potentially untrusted location like removable storage. However, this would not provide security, merely prevent some mistakes (at the cost of annoying users). Very serious mistakes are sometimes worth such hassle - see for example the --no-preserve-root option on rm, which exists because people sometimes accidentally nuke the root of their drive (and basically never do so on purpose, so it's now prevented by default) - but that's not a security feature.

1 This is configurable, if you really want to turn it on. It's not generally useful on Windows, though, because Windows file permissions are by default mostly inherited from the containing directory, rather than being determined mostly by the user's umask. In other words, while in Linux it's actually moderately common to have a situation where a directory isn't readable (to non-owners) but its contents are (because the default umask makes files world-readable); in such a situation, only the traverse (execute) permission on the directory prevents arbitrary users from reading the files. On Windows this very rarely happens. Unless somebody deliberately alters the directory's ACL in a weird way (make other users able to read contained objects even though they can't read the directory itself) or the file's permissions (to add non-inherited read access for other users), the traverse permission on the directory isn't really doing anything other than technically allowing people who guess the file's exact path to confirm its existence, so the traverse permission isn't considered important to enforce.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .