To get the most from this article, you should have experience working with desktop applications in a Windows environment. I assume readers have a basic understanding of how to use the Linux desktop. It's beneficial to have a working Linux computer to explore the concepts and examples in this article.
Sometimes running an application on Linux for the first time requires a
little extra work. Some applications such as server services might not be
installed as services, so you need to start those applications from the
command line. For the user accounts that start the applications,
set the execute permission flag (
x)on the application files.
Running user-space applications
Linux runs processes in kernel space or user space. User space is the area of the operating system where applications typically run. Simply put, each user account has its own user space, and applications work within that realm.
Only the root user has access to kernel space by default. The root user is the superuser in Linux, comparable to the administrator account in Windows. Running an application under the root user account can pose a security risk and is not advisable.
Many server services need root permission to start the service. However, after the service is started, the root typically hands it off to a service account. Service accounts in Linux are technically standard user accounts. The primary difference is that service accounts are used only for running a service and aren't intended for anyone to actually log in with them.
Setting the permissions
You can set the execute permissions on a file with the
chmod command. The
umask setting in Linux typically prevents a
downloaded file from being executable, for good reason too because it can
help maintain the security of your Linux computer.
Most Linux distributions have a
umask setting of
022, which means by default a new file has
permission settings of
644. The numeric
representation of permissions take the form of read (4), write (2), and
execute (1). So an application download with the default permission of
644 means the file owner has read and write
permission, while the group owner and other have read-only permission.
For example, to give everyone execute permission on a file, use the
chmod a+x command. The
a represents all, the plus sign
+) represents add, and
x means execute. Likewise, if the
application is a server service, you should ensure only authorized
accounts have access to execute the service.
If an application is capable of running under standard user account permissions but only those in a particular group need access to use it, you can set the group owner permission to executable and add the users to a group.
Getting even more specific, you can also set access control list (ACL)
permissions on an executable file to allow a particular user or group the
permission to run the application. Use the
setfacl utility to set ACL permissions.
For those applications, such as server services, that need to start the process as root user, you have a few options. Table 1 summarizes various options that allow users to execute server services that require root privileges.
Table 1. Options to run applications that require root privileges
|As root user||Not recommended for server services. Acceptable for applications when users already know the root password and the compromise of the application is not a primary concern.|
|Not recommended due to security issues.
|Commonly used and considered a good practice.
|Standard user account with file permissions||Set execute permission on a file for the user owner, group owner, or other (everyone). This is a common way to grant users who do not require root privileges permission to execute an application.|
|Standard user account with ACL permissions||Less commonly used, but a viable solution when you don't want to
grant a user |
Running from the command line
Running an application from the command line is an essential task when managing Linux servers. A lot of applications have shell scripts—similar to Windows batch files (.bat)—that start the applications and 