Under the /dev , there are some new ttyUSB files. Currently, the owner is root, how can i change to user of system?
I found the owner of /dev/ttyS0 is ubuntu. the user ubuntu is the default user . I want to know how to change the owner of ttyS0. Then i can modify the owner of ttyUSB*
Tks!
As the following:
crw------- 1 ubuntu tty 4, 64 Jul 21 18:51 ttyS0
Those files are not actually files…they don’t exist on the hard drive. This is actually a driver pretending to be a file, and permissions don’t work the same way with these as it does for ordinary files. Changing the owner is probably the incorrect way to work with these. You could dig into customizing “udev”, but it isn’t necessary. What you really want to do is your your user to the group of the file. However, you have another issue…
When you look at all of these serial devices notice who the group is:
ls -l /dev/ttyS* /dev/ttyUSB* /dev/ttyTHS*
Note: The “ttyS*” and “ttyTHS*” of a given number are the same hardware. The two different names are due to having two drivers which can work with the device. You’d only choose to use one at a time, and if either of those two naming convention devices have a “tty” group (described below), then both must be treated as tty.
The “ttyUSB” devices are the ones which are from an FTDI brand serial UART, whereas the others are integrated on the Jetson. You will see basically one of two groups:
ttydialout
In the case of dialout anyone in group dialout can use the device. For example, for user ubuntu:
sudo usermod -aG dialout ubuntu
In the case of “tty” it implies the port is already spoken for by one of the terminal services. You can’t use this unless you expect to reach a console with a serial console program.
In the case of no group permission, then it is likely for security reasons. Imagine if anyone could see or inject text to the terminal of another user. However, since user “ubuntu” owns the one you mention, and it already has read/write permission, then that user will not have an issue reading or writing. The part which isn’t obvious is that since this is a driver and not a real file that the kernel driver is in charge of what to do with any read or write. Such a file is just following its coding.
Tks!
But i want to know where does the owner is changed to ubuntu?
That typically isn’t possible, at least not without “bad behavior” use of udev. Since the file is RAM owned by the drivers it isn’t possible to just change ownership or permission. This is part of the kernel code. In the case of something which is a terminal (something with group tty) this is a security issue and even more difficult. Do you just need access, or do you really need ownership? If you need ownership I suspect all you will find is frustration. If the file is group tty, then you won’t be able to get access the way you could for a serial UART which doesn’t have some program owning it.
Dear sir:
Tks for your reply!
Actually, my question is where does the owner of ttyS0 is changed to ubuntu?
Because the owner of ttyS1 and ttyS2 are root ,it is different. so i think it must be changed in rootfs somewhere 。
crw------- 1 ubuntu tty 4, 64 Oct 28 17:20 ttyS0
crw-rw---- 1 root dialout 4, 65 Oct 28 17:20 ttyS1
crw-rw---- 1 root dialout 4, 66 Oct 28 17:20 ttyS2
Ownership starts with how the driver is coded. From there it starts as group “dialout”. All of the UARTs are owned by root, but you’ll find the group is what changes most of the time. Certain applications, when they take ownership of the port, cause a change in group via the udev system. udev triggers upon creation of device special files, and custom udev specifications can cause the group to change (and technically also the owner). If the group is not dialout for a serial UART, then something else owns the device and you’ll have bad results if two applications try to use the port at the same time.
udev has some standard ownership and group settings based on the Ubuntu packages for udev. If you look at “/etc/udev/rules.d”, then you’ll find rules which either override those rules, or install a rule which was not normally part of the system. Often an optional standard rule will appear in “/etc/udev/rules.d” as a way to turn on the option. Files in “/etc/udev/rules.d” which have the same name as the same udev rule which is standard are usually edits to that original rule…remove the file from “/etc/udev/rules.d” and the rule reverts to the system rule.
I have to emphasize that you should not mess with ttyS0 permissions when the group name is “tty”. This means something has locked the UART for the purpose of acting as a console, and there are consequences beyond just changing ownership or group.
Serial UARTs with group “dialout” are free for your use and have no previous owner.
rootfs does not change permissions unless someone has entered a custom udev rule, typically located at “/etc/udev/rules.d”. The filesystem itself is not involved because driver generated files are in RAM and do not exist on disk. Even when someone “creates” a device special file with something like “mknod”, this is only a name placeholder, and all content comes from the driver itself.
Note that the system default version of various rules is at “/lib/udev/rules.d”, and that these should never be modified. Files of the same name in “/etc/udev/rules.d” as that of a standard udev file are how you would override the system file.
It is very likely that when the serial console was bound to ttyS0 that the login name chosen was for ubuntu. This is why owner is ubuntu, and group is tty. If the system were altered to set login to some other user name, then owner would have been changed (by the driver or udev) to that other user name.
The ttyS# files are just ones using a legacy driver. The reason these are important is because that is the driver the bootloader has. The ttyTHS# files are NVIDIA drivers to the same hardware, but they don’t exist in the bootloader. Thus, to keep serial console running continuously in both bootloader and during transfer to the Linux kernel, it is necessary to use the legacy driver. Had the driver been changed as it booted into Linux, then there would be a gap in logging as the new driver loaded.
Drivers producing UART names with “ttyUSB#” are usually for FTDI UARTs. Other brands of serial UART hardware would use different naming conventions. Companies which want to customize this install a udev package which detects their hardware and renames the file to some custom name.
What is it that you really want to accomplish? If you really want to work on this you should learn how to customize udev rules. It isn’t too hard, but there is some learning curve. Trying to change owners and other details of a UART which is already in use will always behave wrong, and you’d have to disable the application currently using the UART before you could make any changes. If the group is tty, then don’t mess with it. If the group is dialout, then add your user to group dialout and feel free to use the UART for any purpose.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.