A user has use of an application running on a Linux server.  The application provides the user with an API that allows reading and writing files on the server, but does not offer any means of executing a file. Is that enough to ensure the user cannot execute commands on the server?The underlying filesystem is not mounted with noexec. The user can choose which file to read and write, and can create new files with arbitrary names. The user can delete files. The application does not have access to system files, running as a relatively standard unprivileged user account similar to what a desktop user would have. 
If a user can only read and write files, is that sufficient to prevent execution?
permissions;security;executable
Arbitrary names at arbitrary locations, limited only by filesystem permissions is probably escalatable to execute arbitrary code. There are a lot of files in $HOME that are automatically run upon login, for example. And new ones are added (e.g., all the systemd user session stuff is fairly recent). Or maybe $HOME/bin is by default put at the front of $PATH.Other good targets for an attacker would be ~/.ssh; I wasn't supposed to have login access, but will I once I install an authorized keys file? You can of course disable this via config in /etc/ssh/, but that's just one program. There are probably others.I have no doubt you could secure this, but it'd be a lot of work (and you'd have to be very careful on OS upgrades!)If however you can limit it to arbitrary files, but limited to certain directories (say, only in /srv/yourapp/ and subdirs), that is safe (provided its programmed correctly).