Bug 437680 - [RFE] Add warning dialog + posibility to manage dialout group or device permissions for /dev/ttyACM0 directly from the phone manager application
[RFE] Add warning dialog + posibility to manage dialout group or device permi...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-phone-manager (Show other bugs)
16
All Linux
medium Severity medium
: ---
: ---
Assigned To: Linus Walleij
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 740649
  Show dependency treegraph
 
Reported: 2008-03-16 06:42 EDT by Daniel Qarras
Modified: 2013-02-13 21:36 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 740649 (view as bug list)
Environment:
Last Closed: 2013-02-13 21:36:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Qarras 2008-03-16 06:42:30 EDT
Description of problem:
When attaching a mobile phone via a serial/USB cable to my laptop the device
file /dev/ttyACM0 is created for it. It works otherwise all ok but its
permissions are 0660 and owners root:uucp so a normal user plugging the phone is
not allowed to access it.

Version-Release number of selected component (if applicable):
udev-118-1.fc8

How reproducible:
Always.

Steps to Reproduce:
1. Connect a phone via serial/USB cable to your machine
2. Notice how the device file /dev/ttyACM0 is created
3. Notice how the device file permissions are suitable for a normal user
  
Actual results:
crw-rw---- 1 root uucp 166, 0 Mar 16 12:33 /dev/ttyACM0


Expected results:
crw-rw-rw- 1 root uucp 166, 0 Mar 16 12:33 /dev/ttyACM0

Additional info:
This causes application like gnome-phone-manager to be unusable for normal users.
Comment 1 Harald Hoyer 2008-04-23 06:17:21 EDT
maybe HAL should set ACLs for it..
Comment 2 Daniel Qarras 2008-05-05 18:31:40 EDT
This problem remains with F9.
Comment 3 Bug Zapper 2008-05-14 02:38:27 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Pavel Starek 2008-05-17 13:48:45 EDT
Add your normal (non root user) account to uucp group in system-config-users
utility. This will solve your problem.
Comment 5 John Poelstra 2008-10-15 17:29:06 EDT
This bug has been triaged
Comment 6 Bug Zapper 2008-11-25 21:09:21 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Daniel Qarras 2009-04-03 11:01:14 EDT
> Add your normal (non root user) account to uucp group in
> system-config-users utility. This will solve your problem.

Yes, but for many users that's something they are not aware of and are not skilled enough to do. And also, now with F11ß the file /dev/ttyACM0 is owned by root:dialout NOT by root:uucp.

I really hope this could be handled automagically.
Comment 8 Bug Zapper 2009-06-09 05:30:04 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Daniel Qarras 2009-12-04 14:44:24 EST
Not sure is this actually worth the effort but I still think this would be a nice-to-have feature. Any additional insights welcome.
Comment 10 nicofo 2009-12-24 11:20:48 EST
I agree with Daniel Qarras: same problem for me: I was not able to connect to my mobile phone as a normal user (it was only possible with root :-(  ) because of this permission problem (or bug ?).
Adding the normal user to dialout group works, but it's not something a normal user used to do.
Comment 11 Bug Zapper 2010-03-15 07:58:44 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Fedora Admin XMLRPC Client 2011-10-20 12:09:22 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Fedora Admin XMLRPC Client 2011-10-20 12:11:39 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Fedora Admin XMLRPC Client 2011-10-20 12:13:26 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 15 Fedora Admin XMLRPC Client 2011-10-20 12:17:52 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 16 Jaromír Cápík 2011-12-15 11:50:51 EST
Hello guys.

Your request unfortunately affects the system security concept negatively. 
the permissions are set to 660 on purpose and I'm strongly convinced, that they should stay like that. 

The right solution lies in any kind of warning (why it doesn't work) and hint (how to solve the issue) displayed by the phone software trying to access the ttyACM0 device. The software could additionally ask user for the root password and help him with altering the dialup group.

I'm changing the component to 'gnome-phone-manager' as this is a new RFE. If You use a different software, please, create a new feature request against it.
Comment 17 Jaromír Cápík 2011-12-15 12:56:20 EST
Sorry .... typo .... dialup -> dialout
Comment 18 Linus Walleij 2012-01-02 09:53:49 EST
INCIDENTALLY I filed a similar bug directly to the udev authors
requesting that not ttyACM0 but just something as peculiar as
ttyUSB0 be made writeable by the logged-in user, which would
solve also this problem I suspect:
http://www.spinics.net/lists/hotplug/msg04975.html

Now, the good udev developers have told me that users may use
this to dial out to expensive numbers, and since they believe
that modems attached to machines you can log onto should simply
not be accessible by you by default but after asking the root
to add you to the "dialout" group, there is not much we can
do about it.

(My follow-up question to what to do about the security threats
we expose by allowing all users to access plugged-in cameras
and media players were subsequently ignored.)

They suggested that we patch Anaconda to auto-add users to the
"dialout" group instead.

But I'm reassigning to Fedora udev maintainers to get an
opinion on this. (Maybe they're willing to carry the patch
in the linked message?)
Comment 19 Linus Walleij 2012-01-02 10:02:00 EST
> Your request unfortunately affects the system security concept negatively. 
> the permissions are set to 660 on purpose and I'm strongly convinced, that they
> should stay like that. 

In a world where a majority of Fedora systems with attached tty:s
are connected to modems that can be used to dial out to pay-numbers this
is trie.

In a world where everyone has an ethernet connection or 3G modem and use
their tty for other stuff, like managing their own phone with something like
gnome-phone-manager or accessing the console of some other machine, this is
false.

Typical user assumptions is among the hardest things, myself I haven't seen
a modem since the early 1990's, and would suspect that most people are not
using Fedora to run modem dial-ups, indeed maybe noone. But who am I to
speak of such things...
Comment 20 Linus Walleij 2012-01-02 10:07:19 EST
I'm adding Alan Cox to the CC to see if we can get an experienced
Linux oldtimer perspective on this issue.
Comment 21 Kay Sievers 2012-01-02 10:28:54 EST
Modems are handled in a secure way by ModemManger and must never by default
get raw permissions set up for untrusted users, regardless if they are
locally logged in or not.
Comment 22 Jaromír Cápík 2012-01-03 10:45:47 EST
Guys, I'm not satisfied with the bug enclosure. I still believe, the right solution lies in the ability of the phone software to alter the groups (the same behaviour can be noticed in case of K3b - CD burning software, so ... it isn't just a blurry vision, it's an already known solution for similar issue!). 

I'm changing the component back to the gnome-phone-manager + reopening the bug.
Comment 23 alan 2012-01-03 11:27:03 EST
Firstly ttyACM isn't necessarily a phone, it might be things like robot controllers, model railway control systems and who knows what.

Secondly I think Kay is right (which isn't something I say often!). Probably the modem managers need to provide a mediated interface for user run phone software so that phone apps can ask do to do things, and the administrator can if need be make a policy decision where it has a cost. You need to mediate it anyway because if you have two apps trying to talk to the phone at the same moment it will make a nasty mess, particularly if you've got a device that is using the GSM mux protocol to do multiple channels as some US modems in particular seem to do.

The situation hasn't changed - hostile software could phone on modems, it can equally make very expensive mobile phone calls to premium numbers owned by criminals as is happening today in various bits of phone related malware.

If anything the interface should be more restrictive not less.

Jaromir: CD isn't equivalent - with K3B I can maliciously break your CD burn.. whoopee. With a mobile phone I can run off with lots of your money. Different order of magnitude of threat.
Comment 24 Jaromír Cápík 2012-01-03 12:15:56 EST
Hello Alan.

I can imagine many better solutions, but the question is what the phone application can do if such solution is not available and when it simply can't access the device. The application should provide users with detailed explanation of the security risks, but then it should offer them some kind of help with the group membership modification, because that's what 95% of users will do manually if they encounter such issue (usually with some internet searching and screaming) since there's usually no other solution (and explanation) available.

Yes, You're right ... the ttyACM device can be used by different devices and that should be also mentioned in the warning. Users are legally competent to decide if they want to risk security issues or not. Most of the users have root password for their system and they must be aware of all risks when they enter the root password.

So ... regardless of the other solutions, the application should be able to warn users and help them to solve the situation somehow. Providing users with explanation could be the needed minimum to avoid their anger. Otherwise it could be considered as ignorance or maybe even arrogance from our side. We create the face of opensource products and it's our responsibility to make them as much comfortable as possible.

I would like to ask You to reconsider it.
Thank You.

Regards,
Jaromir.
Comment 25 Jaromír Cápík 2012-01-03 12:26:45 EST
Btw. I'm a fan of any kind of mediated interface taking care of the situation. That could be offered as primary choice once it is implemented.
Comment 26 Linus Walleij 2012-01-16 01:55:40 EST
So how should one proceed to fix this up?

I don't know a way to solve the ttyS* ttyACM* access problem generically,
if we could fire a desktop requester whenever someone attempts to access that
node so they get the option to add themselves to the "dialout" grouo we
could make a generic solution.

Would it be possible to simply set up a service that register inotify
to IN_OPEN, at that point check if logged-in user has write access to the
file and in case s/he hasn't pop up a requester?

That seems like it could work, but would be a complete stand-alone
service.

What do you guys say?

BTW can someone point me to some contemporary code that pops up GNOME3
requesters on the desktop for different stuff?
Comment 27 Fedora End Of Life 2012-08-07 15:24:26 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 Fedora End Of Life 2013-01-16 20:03:15 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Jaromír Cápík 2013-01-18 07:14:36 EST
Hello Linus.

Any news here?

Thanks,
Jaromir.
Comment 30 Fedora End Of Life 2013-02-13 21:36:33 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.