Bugzilla Bug 223757

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 an attachment (id=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.