app-mobilephone/kmobiletools-0.5.0_beta3 is requesting root priviledges and after that it adds normal user to root group --- output (when running from terminal)-- kbuildsycoca running... Adding user XXXXXX to group root Adding user XXXXXX to group uucp Weaver::finish: done. Reproducible: Always Steps to Reproduce: 1.emerge app-mobilephone/kmobiletools-0.5.0_beta3 2.Run the wizard 3.Fill in the root password 4.Add new device Actual Results: app-mobilephone/kmobiletools-0.5.0_beta3 is requesting root priviledges and after that it adds normal user to root group I think is very very insecure what it happens. I might do something wrong and end up with my user to root group but I double checked it on two machines
KDE/Mobile, can you guys look into this?
I guess we'll have to talk with upstream...
I can confirm it does happen. 'RockMan' might know why this is happening.
Sorry, I looked again at it. It does NOT happen to me.
17:44 <deathwing01> do you want me to add you to the bug? 17:45 <RockMan> ok, but please post a comment: i need a precise log to see if it's a bug or not 17:46 <RockMan> because, if we have, for instance, /var/lock belonging to root:root then the normal (and wanted) application behaviour is to add the current user to that group (that's root) 17:46 <RockMan> so if you've root:root in one of that items it's a distro-configuration bug.. that's all 17:47 <deathwing01> I have to say that my user already belonged to uucp group
So, from instructions on comment #5: $ ls -ald /var/lock In my case, where the bug is not reproducible: drwxrwxr-x 3 root uucp 96 2008-05-31 02:13 /var/lock What about you?
So this is the /etc/group for Group *root* before I execute kmobile tools root:x:0:root Then I execute the kmobiletools Then it asks me for root password I give it to it. It says that my user will be added to groups uucp and root. Then Adding user hwoarang to group root Adding user hwoarang to group uucp And after that cat /etc/group|grep root root:x:0:root,*myuser* Is this behavior normal? ps: ls -ald /var/lock/ drwxrwxr-x 3 root uucp 4096 2008-04-11 08:58 /var/lock/
Could you show us the permissions of rfcomm* ttyS* ttyACM* ttyUSB* ircomm* files in /dev? Additionally, could you attach a full log? Thanks.
ls -la /dev/|grep rfcomm* crw-rw---- 1 root root 216, 0 2008-06-02 15:24 rfcomm0 ls -la /dev/ttyS* crw-rw---- 1 root uucp 4, 64 2008-06-02 18:24 /dev/ttyS0 crw-rw---- 1 root uucp 4, 65 2008-06-02 15:36 /dev/ttyS1 crw-rw---- 1 root uucp 4, 66 2008-06-02 18:24 /dev/ttyS2 crw-rw---- 1 root uucp 4, 67 2008-06-02 18:24 /dev/ttyS3
(In reply to comment #9) > ls -la /dev/|grep rfcomm* > crw-rw---- 1 root root 216, 0 2008-06-02 15:24 rfcomm0 You just found the problem. This device does not belong to the appropriate group.
Indeed. That did the trick Fixed and closed now i guess ;)
I'd like to have base system verify that these devices are created with the appropriate permissions. Base system herd, could you please confirm? Additionally, I think I will add a permissions check to the ebuild or a permissions autofix to the ebuild so that the application does not add users to the root group. Finally, a bug report upstream asking to implement that functionality internally.
anyone who adds random users to the root group should get smacked with a basic permissions howto anyways ;) device permissions is handled by udev ... if there is a central package for it, you should have it include a custom rules.d file. if there isnt, you'll need udev to include an appropriate rule so that it gets uucp group ownership. looking at existing udev rules.d, you'll probably want to just update the rule which sets uucp ownership for ircomm/etc...
Thats true But how could we add an *EXTRA* udev rule for rfcomm port ? Cause I changed rfcomm port group to uucp and after I rebooted the group changed to root again
Maybe something like KERNEL=="rfcomm[0-9]", NAME="rfcomm%n" ,GROUP="uucp"
(In reply to comment #15) > Maybe something like > > > > KERNEL=="rfcomm[0-9]", NAME="rfcomm%n" ,GROUP="uucp" > This may sure help, but still can be simplified to: KERNEL=="rfcomm[0-9]*", GROUP="uucp" If we are needed to add this to udev-ebuild, I suggest to enhance this rule from /etc/udev/rules.d/65-permissions.rules: KERNEL=="ippp*|isdn*|dcbri*|capi*", GROUP="uucp" But: My system contains /etc/udev/rules.d/70-bluetooth.rules which has this: SUBSYSTEM=="tty", SUBSYSTEMS=="bluetooth", GROUP="uucp" Doesn't this match rfcomm devices? Please add info about versions of kernel, udev and bluez-utils you have on your system.
The rule I posted works fine for me even after i rebooted Here are my info 2.6.24-gentoo-r8 udev-119 bluez-utils-3.30
Please also attach the output of udevinfo -a -n /dev/rfcomm0
Created attachment 155811 [details] udevinfo for rfcomm port
udev-122-r1 does now set GROUP="uucp" for rfcomm* devices.
I think I'll add an extra check to the ebuild. Is it possible to have udev-122-r1 stabilized?
udev team, ping.
If no big issues show up I vote for stablizing udev-124.
No big issues within which timeframe?
The only issue I know of with udev-124 is this: http://thread.gmane.org/gmane.linux.hotplug.devel/12858 But it seems this is not yet fixed. Nevertheless I think the time is over, else we forget about this again. :)
Is this bug now fixed? The relevant ebuild (kmobiletools-0.5.0_beta3) is marked ~amd64 ~ppc ~x86 and fixed udev-124-r1 is marked amd64 ~ppc x86
This issue only affects the unstable =app-mobilephone/kmobiletools-0.5.0_beta3 and not our stable version =app-mobilephone/kmobiletools-0.4.3.3 The code to add the current user to the groups that are gid of /dev/{rfcomm,ttyS,ttyACM,ttyUSB,ircomm}* /var/lock seems to have been added in the 0.5 series. With udev setting proper group rules for all of these devices, this issue is fixed when all arches have stabled =sys-fs/udev-124-r1 per bug 233790. We do not need the kmobiletools-0.5.0_beta3 stable, and this issue will not result in a GLSA since it did not affect stable ebuilds. Matthias, thanks for getting udev fixed and stable, and sorry for Security's lack of communication the last days.
For what it's worth, this is not a security issue, because no trust boundaries are crossed. The user has to provide the root password to acquire being added to the root group, and there is no way to force this without the password. It is an unexpected and undesired behavior, and therefore a bug in udev/kmobiletools. Since we are stabling udev in the other bug, and there is nothing else to do for this bug, I'll close it FIXED. Thanks to everyone for the feedback.
