Bug 293

Summary:	Minicom does not lock
Product:	Mageia	Reporter:	Juergen Harms <juergen.harms>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Normal	CC:	dmorganec
Version:	Cauldron
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	minicom	CVE:
Status comment:
Attachments:	patch for fixing the problem as described in the comment

Description Juergen Harms 2011-03-06 18:21:47 CET

Description of problem:

Minicom has a locking feature that should allow to avoid having multiple sessions accessing a single tty port (normally /dev/ttyS0).

The recently made available minicom package evidently does not create such a lock

Version-Release number of selected component (if applicable): minicom-2.5-1.mga1

How reproducible:
100%

Steps to Reproduce:
1. from a console start minicom
2. from another console try to start minicom
3. that should be rejected with an error message, but is not, I get 2 sessions which disorderly access the tty-port.

Doing "Ctrl-A/O -> Serial port setup" displays that the lockfile is /var/lock/tty as the lockfile (i.e the default configuration), but "ls -la /var/lock/tty" shows that no lock file exists in that directory.

Background / history
--------------------
In past (Mandriva) releases, there was a small bug: minicom created the lock file directly in /var/lock (disregarding the configuration established by minicom ->Ctrl-A/Z ...) - which immediately resulted in the failure of minicom to start since /var/lock belonged to root:uucp (minicom belongs to root:dialout); changing ownership of /var/lock to root:dialout therefore provided a -for me - satisfactory workaround.
( ls -la /var/lock illustrated that minicom created 3 lock-files in that directory)

Ugly, but allowing to work with minicom with a safeguard against locking. I did not file a bug since it works perfectly for me and I do not think that minicom has many users.

In the new implementation that is now available in mageia, I do not need to modify the ownership of /var/lock any more since minicom does not try to create a lock file at all - a situation which is dangerous: no more locking against accidental multiple access to minicom.

Note: minicom may look like a somewhat archaic tool - using Unix tools (avr tool chain) for doing microprocessor software developement, minicom is essential for displaying data sent from the serial port of the microprocessor.

Reproducible:

Steps to Reproduce:

Comment 1 Juergen Harms 2011-03-07 07:57:48 CET

I have now looked at the SRPM and found a fix - see the patch in the attachment

There appear to be 2 problems, both created in the file minicom-2.5/configure

1. Bad lock directory (/var/lock rather than /var/lock/tty)
- configure finds the directory for the lock file by serially exploring a list of directory names hardwired into the code of configure
- the lock directory is set to the first directory of that list which exists
- the list of directory files (line #7720 of configure) does not contain /var/lock/tty.

This is fixed by correcting the list of directory names in line #7720 and adding "/var/lock/tty" BEFORE "/var/lock" 

2. Bad lock file name
- minicom derives the name of the lockfile from the name of the device for serial IO
- again, configure does this by scanning a list of device names and deciding on the first one that exists
- that list contains /dev/ttyS1 - on my laptop ttyS0 through ttyS3 exist as nodes in /dev - therefore minicom uses ttyS1
- but, physically, my system configures its serial device on /dev/ttyS0
- before creating the lockfile, minicom checks (main.c) for the physical existance of the device and - since there is no physical /dev/ttyS1 on my machine - the creation of the lockfile fails.

I patched this by modifying the name in the list of serial devices scanned by configure from /dev/ttyS1 to /dev/ttyS0. This is only a quick fix, the correct solution would be to replace the scan for node names by a scan for existing devices - I doubt whether this is worth while.

There appears to be a fundamental problem in the implementation of minicom: the "configure" mechanism is not really compatible with the design of the dynamic configuration mechanism in minicom. But again, probably not worth while to invest time.

There is a third thing that needs to be corrected:

3. /var/lock/tty must have ownership root:dialout (and not root:uucp). Again, somewhat problematic in case there is software around that expects the old ownership of the tty directory - but, is uucp still in use?

Making these 3 changes, minicom works with locking as it should

But I will start looking for another terminal emulator (-

Comment 2 Juergen Harms 2011-03-07 08:01:02 CET

Created attachment 95 [details]
patch for fixing the problem as described in the comment

I practically never used diff and patch - I used "diff -u". I hope that this is OK

Comment 3 Juergen Harms 2011-03-24 21:17:27 CET

Appears to have been fixed in minicom 2.5-2

Comment 4 D Morgan 2011-03-25 00:08:15 CET

tks closing

Status: NEW => RESOLVED
CC: (none) => dmorganec
Resolution: (none) => FIXED
Source RPM: minicom-2.5-1.mga1 => minicom