Accessing serial ports in Linux

One of the first things users of APRO/CLX will likely discover is that accessing serial ports is a bit different in Linux than it is in Windows.

One of the biggest differences centers on the default rights or permissions of the serial devices themselves. In all versions of the Windows operating system, any valid user on the system can pretty much freely use hardware devices (such as the serial port(s)) by default. Windows is a very trusting operating system.

Linux isn’t so trusting by default. A file listing of a typical serial device, /dev/ttyS0, on a Linux system looks something like this:

crw-rw----    1 root     uucp       4,  64 Apr  3 12:41 /dev/ttyS0

A quick summary of what all this means in terms of file permissions:

The owner of file and members of the file’s group have read/write access. The owner of the file/device is ‘root’ and the group is ‘uucp’. These permissions and ownership settings seem to be pretty consistent for most Linux distributions, but keep in mind that you might run across some slight variations for whatever reason.

An average user on a Linux system is not likely to belong to the uucp group, and shouldn’t be root – so it’s easy to see that the typical user will not be able to access the serial port by default.

This obviously impacts anyone expecting to use an APRO/CLX application as non-root.

What’s the solution? There’s no single ‘perfect’ solution that would be ideal for all situations – but there are several reasonable possibilities to consider, depending on how the application (and its host operating system) is being used.

Here are a few possible solutions to consider:

Run the Application as Root

It’s usually best to minimize what is done as root, so this probably isn’t a good idea if it can be avoided – but it’s a valid solution nevertheless and may be appropriate in some situations. Simply log in as root and run the application.

Give Everyone Access to the Device

The simplest solution is to change the permissions of the desired file so that everyone has read/write access.

This can be done from a command prompt using the chmod command (you’ll need to be logged in as root to do this).

The chmod command has different ways of defining the desired permissions. Both commands shown below are equivalent and will give all users access to the serial port (you need to run one or the other, not both):

# chmod 666 /dev/ttyS0

# chmod a+rw /dev/ttyS0

From a security standpoint, giving everyone read/write access to your serial port isn’t always such a good idea. If the system in question serves multiple users or is connected to the Internet, this may not be a good solution.

Add Appropriate Users to the UUCP Group

Another possible way to approach the problem is to add all users requiring serial port access to the uucp group. Any user added to the uucp group will have full read/write access to all uucp devices. Adding a user to a group can be done with the usermod command (again, you’ll need to be logged as root):

# usermod –G myuser,uucp myuser

This is usually a pretty good solution, because it gives fairly tight control over who can access the serial port. The only potential downside is that users added to the uucp group will have access to all uucp files and devices.

You may notice that myuser was added to both the myuser group and the uucp group in the example above. This assumes myuser was already in the myuser group, and wanted to remain a member of the myuser group.

Change Ownership of the Device

If you’re certain that only one user will need access to the serial port, changing the device’s owner and group to match that of the user needing access might be a reasonable possibility. This is done with the chown and chgrp commands:

# chown myuser /dev/ttyS0

# chgrp myuser /dev/ttyS0

This approach has a few advantages. It gives tight control over who can access the device without giving the user (or the application) too much access to the rest of the system.

A possible disadvantage to this approach is that you might disrupt access to another user that had access to (and was using) the device, so keep an eye open for this kind of thing.

Give the Application Access

Another potential approach to the problem is to set the application itself to assume the required User ID (UID) or Group ID (GID). Such applications are known as Set-UID or Set-GID applications.

The chmod command is used to set the Set-UID or Set-GID bits of an application. With one of these bits set, the application will assume the UID or GID assigned to the file – even if the user executing the application isn’t the user (or doesn’t belong to the group) in question.

To set the Set-UID bit, add a 4 to the beginning of the applications’s desired filemask:

# chmod 4744 myapp

To set the Set-GID bit, add a 2 to the beginning of the application’s desired filemask:

# chmod 2744 myapp

This practice is generally frowned upon from a security standpoint, so it shouldn’t be used unless it’s the best option (and you fully understand the potential security problems).

This site is not affiliated, endorsed, or otherwise associated with the entity formerly known as TurboPower Software. The owners and maintainers of Aprozilla.com were merely meager employees of the aforementioned organization, providing this site out of the pure goodness of their collective hearts. SourceForge.net Logo

Last updated: July 22, 2003.