Fedora Account System
Red Hat Associate
Red Hat Customer
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.
maybe HAL should set ACLs for it..
This problem remains with F9.
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
Add your normal (non root user) account to uucp group in system-config-users utility. This will solve your problem.
This bug has been triaged
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
> 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.
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
Not sure is this actually worth the effort but I still think this would be a nice-to-have feature. Any additional insights welcome.
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.
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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
Sorry .... typo .... dialup -> dialout
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?)
> 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...
I'm adding Alan Cox to the CC to see if we can get an experienced Linux oldtimer perspective on this issue.
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.
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.
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.
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.
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.
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?
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
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
Hello Linus. Any news here? Thanks, Jaromir.
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.