The minicom package (a serial communications package) uses a lock file to control access to the serial port it's using. The problem is, the lock file defaults to /var/lock/, but your average user doesn't have write access to that directory. The default install should make a directory like /var/lock/tty/, and make minicom use that directory. Then a user in the tty directory can use minicom and the lock file will be created correctly. Reproducible: Always Steps to Reproduce: 1.open the default install of minicom as a limited user Actual Results: Minicom exits because it can't create the lock file. Expected Results: Started.
the locking mechanism is supposed to offer exclusive access to some file/device (in this case serial port). what do you think it will happen if minicom will try to use /dev/ttyS0 when another application (lets say faxgetty) use it for sending a fax, application that knows only about /var/lock? you must be member in uucp group in order to lock a resource, but you can choose not to use locking mechanism if you want to (hint: minicom -s).
I don't think so. On my machine (and I haven't changed this) I have: drwxrwxr-x 4 root uucp 4096 Sep 10 08:03 /var/lock And it is obviously available for users to create lock files in. Note that users of minicom should be in the uucp group so they can create the lock file. This has traditionaly been the way that access to the modem has been regulated. There is a problem here though: -rwxr-xr-x 1 root root 172312 Apr 11 10:14 /usr/bin/minicom as minicom should be installed SGID uucp so that it can open the /dev/ttyS? device. Which brings up another problem: /dev/ttyS? are links to /dev/tts/? crw-rw---- 1 root tty 4, 64 Sep 10 08:03 /dev/tts/0 and they should be owned by the uucp group to be able to be opened with minicom when it is SGID uucp. This used to be handled by /dev/cua? devices that were for callout and owned by the uucp group. I don't know if simply changing the group on /dev/ttyS? to uucp will break anything else though. I believe that to be a udev issue though. There is a good reason for the deprecating of /dev/cua? in: /usr/kde/3.4/share/doc/HTML/en/kppp/ttyS-cua.txt. (provided that you have KDE installed.) I can create the patch to install minicom SGID uucp but it won't do any good without the group ownership on /dev/ttyS?? getting changed to uucp too and we need a more developer to chime in here.
ok, I will check later if minicom call setegid function.
Another bug that is related is Bug #108069
After research and consultation with the developer in charge here is the deal: 1) You must be a member of the uucp group to create the lock file. (or use the -o option) 2) You must be a member of the tty group to access the serial port. (unless Bug #108069 gets 'fixed'. Then case you must be a member of dialout)
(In reply to comment #5) > 2) You must be a member of the tty group to access the serial port. > (unless Bug #108069 gets 'fixed'. Then case you must be a member of dialout) IMO, you must distinguish between a) the Gentoo default configuration and b) your local setup. a) As I conclude from bug #108069 comment #2, developer's decision is that the default for serial ports should stay at root:tty since there might not in all cases be a modem. (However, other distributions have as default "0660 root:uucp" or "0660 root:dialout". See for example SuSE, Debian or Fedora.) b) If for your local setup there is a modem connected to /dev/ttyS0, I believe it is still preferable to change the group ownership of the port to "uucp" or "dialout" and include the user in this group. Users should not be members of the "tty" group.
fixed in minicom-2.1-r2 by installing minicom with group uucp and set-group-ID permission. now any user could lock the serial devices through using them in minicom, but they must have rw permissions on serial device for being allowed to use it.
Starting from 2.2-r1, minicom is no longer sgided to uucp. See bug 180120 for more info.
