weixin_39760434
2020-12-29 20:34 阅读 11

tty: Bail out if the TTY is not accessible

One common problem when accessing the TTY is that you cannot access it as regular user. The expected behavior is that the TTY terminal application errors this out to the user. TIO is simply looping trying to endlessly access the TTY, leaving the user in the dark about what's going on.

The underlying issue is that the access checking is done in a void returning function (tty_wait_for_device()) that is basically doing nothing when the (access()) function is failing (because the TTY is not accessible).

Move the check for the TTY accessibility at the start, even before configuring the TTY because why do we need to configure a TTY that we cannot even access?

Signed-off-by: Carlo Caione

该提问来源于开源项目:tio/tio

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

11条回答 默认 最新

  • weixin_39733821 weixin_39733821 2020-12-29 20:34

    This seems racy to me. When a TTY is hotplugged, the device node is initially owned by root:root which will make access(2) return non-zero. Only after udev has done its job the device node will have its final permissions.

    点赞 评论 复制链接分享
  • weixin_39760434 weixin_39760434 2020-12-29 20:34

    where do you see the race exactly?

    A couple of points: - Why do you hotplug the TTY with TIO running? The large majority of people just run TIO when the TTY device is already present. It's definitely more likely that you run TIO multiple times with the TTY already present than vice-versa (i.e. think about the usual USB-UART adapter case: you connect the cable, the TTY device is created and then you run TIO, possibly multiple times).

    • udev changes permissions only if the udev rules assert so but this is not generally true. Think again about the FTDI, PL2303 adapters that create /dev/ttyUSB*. In that case the default permission is (rightfully so) 660 (see 60-serial.rules).

    • Also the access() call is not useful at all as used right now.

    点赞 评论 复制链接分享
  • weixin_39760434 weixin_39760434 2020-12-29 20:34

    BTW this fix is needed not only for the specific case of -EACCESS but also for something more trivial as:

    
      % tio /dev/ttyNONEXISTENT
    [tio 13:50:27] tio v1.31
    [tio 13:50:27] Press ctrl-t q to quit
    
    点赞 评论 复制链接分享
  • weixin_39733821 weixin_39733821 2020-12-29 20:34

    where do you see the race exactly?

    In the time between the kernel creating the device node and udev changing ownership/permissions. If tio tries to access at that point, it bails out for no good reason.

    Why do you hotplug the TTY with TIO running? The large majority of people just run TIO when the TTY device is already present. It's definitely more likely that you run TIO multiple times with the TTY already present than vice-versa (i.e. think about the usual USB-UART adapter case: you connect the cable, the TTY device is created and then you run TIO, possibly multiple times).

    I have several embedded boards where e.g. a FT232 is not bus-powered. So every time I power down the board the TTY disappears. tio waiting for it to reappear is THE main feature for me.

    udev changes permissions only if the udev rules assert so but this is not generally true. Think again about the FTDI, PL2303 adapters that create /dev/ttyUSB*. In that case the default permission is (rightfully so) 660 (see 60-serial.rules).

    Exactly. But usually the group changes to sth. like tty, dialout or plugdev. Which is exactly what I'm aiming at.

    Also the access() call is not useful at all as used right now.

    I can't say for sure right now, but I do think it serves a purpose. Would have to re-read the code.

    点赞 评论 复制链接分享
  • weixin_39733821 weixin_39733821 2020-12-29 20:34

    BTW this fix is needed not only for the specific case of -EACCESS but also for something more trivial as:

    
      % tio /dev/ttyNONEXISTENT
    [tio 13:50:27] tio v1.31
    [tio 13:50:27] Press ctrl-t q to quit
    

    As written above, this is not a bug but a feature. Maybe some message like "Waiting for device to become accessible" would help.

    点赞 评论 复制链接分享
  • weixin_39733821 weixin_39733821 2020-12-29 20:34

    Also, please see https://github.com/tio/tio/blob/master/README#L43. Hotplug support is an intended feature of tio.

    点赞 评论 复制链接分享
  • weixin_39760434 weixin_39760434 2020-12-29 20:34

    As written above, this is not a bug but a feature. Maybe some message like "Waiting for device to become accessible" would help.

    Sorry but waiting endlessly for a non-existing / non-accessible device is not a feature. It's extremely confusing and not expected. How many tools do you use everyday that have this kind of behavior?

    Also you are basically ignoring a whole class of problems, not just the specific problem of when the device has the wrong permissions. See the access manpage: you are basically ignoring a lot of stuff, from -ENAMETOOLONG to -EIO to -ENOMEM. Seriously, this is really wrong on so many levels.

    Probably you want to selectively enable the hotplugging story using an argv parameter.

    In the time between the kernel creating the device node and udev changing ownership/permissions. If tio tries to access at that point, it bails out for no good reason.

    This is something that should be fixed by the systemd guys or maybe the tool should be iterate using a script or something. But ignoring a -EACCESS and just pretending that nothing happened, is plain wrong.

    I have several embedded boards where e.g. a FT232 is not bus-powered. So every time I power down the board the TTY disappears. tio waiting for it to reappear is THE main feature for me.

    IMO this should be solved with a script, not forcing this policy on the tool.

    Exactly. But usually the group changes to sth. like tty, dialout or plugdev. Which is exactly what I'm aiming at.

    Yeah, but sometimes it's not just you. Sometimes the story is to write a program that could be used by other people and write it in a way to be easily adoptable, not hardcoded to your specific taste and use cases.

    I can't say for sure right now, but I do think it serves a purpose. Would have to re-read the code.

    No, it doesn't. You are ignoring every kind of return value (again, not just -EACCESS) and just returning in the endless loop.

    点赞 评论 复制链接分享
  • weixin_39640157 weixin_39640157 2020-12-29 20:34

    Guys, you are both right. Yes, as correctly pointed out, the autoconnect feature is absolutely a feature by design. tio will wait for a tty device to appear and connect and in case it disoconnects it will agressively try to reconnect until a successful connection is established. However, is also correct that users are left in the dark about what is going on, especially when errors occur.

    This current silent behaviour is intentional only because I never got around to finishing the error handling and verbosity required to better inform the users.

    When the --no-autoconnect arguement is used tio should exit whenever an error occurs. However, the default behaviour should be to aggressively autoconnect - it is a feature that the majority of tio users appreciate.

    What I want to see in the future is better verbosity and error handling to support example output like this:

    
    [17:02:12] tio v1.32
    [17:02:12] Press ctrl-t q to quit
    [17:02:12] No device found - waiting for device...
    [17:02:12] Device detected
    [17:02:12] Error: Permission denied
    [17:02:12] No device found - waiting for device...
    [17:02:12] Device detected
    [17:02:12] Connected
    

    I don't know when I will have time to add this. However, patches are welcome.

    点赞 评论 复制链接分享
  • weixin_39716417 weixin_39716417 2020-12-29 20:34

    Just a note, I was thrown off by this issue too, but even without this pull request applied, I am just using the -n option to prevent the wait loop. That way my users get an error message:

    
        $ tio /dev/ttyBLAH   
        [tio 15:29:53] tio v1.29  
        [tio 15:29:53] Press ctrl-t q to quit  
        . . . indefinite waiting here until ^tq
        $ tio -n /dev/ttyBLAH  
        [tio 15:30:00] tio v1.29  
        [tio 15:30:00] Press ctrl-t q to quit  
        Error: Could not open tty device (No such file or directory)
    
    点赞 评论 复制链接分享
  • weixin_39640157 weixin_39640157 2020-12-29 20:34

    True, the --no-autoconnect option makes tio print error messages upon error exit. Either way, I expect to improve the normal mode with error messaging soon.

    点赞 评论 复制链接分享
  • weixin_39793189 weixin_39793189 2020-12-29 20:34

    Quoting lundmar 2018-12-16

    I don't know when I will have time to add this. However, patches are welcome.

    Such patch is provided in #105

    点赞 评论 复制链接分享

相关推荐