Serial Com Port 1 Device File Permissions Auto Changed!

[Paul Mai]

Hello,

Problem is occuring on a hp9000 machine

I wanted to connect a Barcode Reader (BCR) to the Serial Com Port1. The Scanner is Microscan MS3

I created the device files via SAM -> "Modems and Terminals" successfully

The device file is:

crw-r--r-- 1 bin bin 1 0x000000 /dev/tty0p0

Next, because I change the permission list to 666 because I need to login as another user (eg. user1) to use the scanner

crw-rw-rw- 1 bin bin 1 0x000000 /dev/tty0p0

When I next login as user1 and try to scan barcodes with the scanner. I noticed that the permission and owner had AUTOMATICALLY changed to:

crw--w--w- 1 root bin 1 0x000000 /dev/tty0p0

I thought that perhaps this had something to do with creating the device file using SAM, so I removed the Device File using "Modems and Terminals".

recreated the device file using mknod and also tried insf -evC, changed the mode to 666 but I still get the owner and permission changed AUTOMATICALLY

I know that the O/S has to write and read to the device file, but in my case, it is also changing the permission and ownership :(

Would very much appreciate it if you can give me some advice about why this is happening and pointers to make the device file correctly for my scanner. Thanks.

[A. Clay Stephenson]

This is normal behavior for a port that is running getty or a getty-like process. THe sequence is that the port is initially owned by root with permissions 622; upon login (which initially runs as uid 0) the ownership is changed to the current user. As soon as the session is finished, another getty is spawned and the process repeats. If you need to change this behavior, you must substitute your own getty-like process for the one currently specified in /etc/inittab for this port. "respawn" instructs the system to start a new process when the old one dies OR change the "respawn" to "off" and assume control of the port through your own software. Another option is to use a process which opens the port, sets initial modes and ownership, baudrate, etc. and then
waits forever. In this case, the process would never terminate so your 666 permissions would remain intact. As long as you are running getty or uugetty, the behavior will be just what you observe and that is both normal and desirable from a security standpoint.