-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Description
Background and motivation
When running external processes such as through the Process class, the MS Learn Docs recommend that data is validated before using it with a Process object. One of the most important things to validate for Processes is whether a file is an executable file and whether the current user has execute permissions on the relevant file.
Determining this in .NET currently is not difficult but requires separate implementations for Unix and Windows, and requires creating/re-creating the code for this functionality in each project where this is required.
API Proposal
I propose 2 new APIs, the IsExecutableFile method for determining if a file is an executable file, and HasExecutePermissions for determining if the current user has execute permissions for the file.
namespace System.IO;
public sealed class FileInfo : FileSystemInfo
{
``public bool IsExecutableFile()``
``public bool HasExecutePermissions()``
}API Usage
// The executable file name could be provided by the user or a project.
FileInfo file = new("pwsh.exe");
// Check if the file is executable
bool isExecutable = file.IsExecutableFile();
// Throw an exception if the file is not an executable file (can't run a non executable file)
if(!isExecutable)
throw new Exception($"File '{0}' is not an executable file", file.FullName);
//Check if the user has execute permissions
bool userHasExecutePermissions = file.HasExecutePermissions();
if(!userHasExecutePermissions)
throw new Exception($"User does not have permission to execute the executable file '{0}'.", file.FullName);
// Create process start info using the specified executable file
ProcessStartInfo startInfo = new(file.FullName);
// Create a process using the specified
Process proces = new Process(startInfo);Alternative Designs
An alternative to a IsExecutableFile method could be to update the FileAttribute enum to add a Executable value for detecting if a file is executable.
An alternative to HasExecutePermissions could be to create a unified cross-platform IO Permission model or update FileSecurity to add convenience methods and support for Unix - this may be suboptimal as FileSecurity is modelled after Windows File Access abstractions which may not translate/map well to Unix paradigms.
Risks
- It's possible the executable file detection API might need to be an asynchronous API for best performance - this could be mitigated by offering both an async version and a non-async version.
- Possible confusion as to differences between
HasExecutePermissionsvsIsExecutableFile- This can be mitigated with clear and distinct doc comments. - It could theoretically lead to suggestions/proposals for other permission convenience methods such as
HasWritePermissionsetc. - The alternative API design for
HasExecutePermissionswould be a breaking change since it would add a new value to an existing enum.