[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-users] Bug report: Linphone replaces a link to .linphonerc

From: linphone
Subject: Re: [Linphone-users] Bug report: Linphone replaces a link to .linphonerc with actual file
Date: Tue, 6 Oct 2015 22:32:17 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

Thank you very much for the update!

I don't have the development environment to compile Linphone, so I couldn't check it.

But I would like to propose a different solution:
- Storage of all Linphone configuration files in a ".linphone" folder of the user home directory. (I.e. $HOME/.linphone instead of the current $HOME.)

- The affected files (.linphonerc, .linphone-history.db, .linphonerc.tmp, etc.), which would then be placed into that directory, could have the leading dot removed from the name.)

- The original patch (see previous e-mail) could then be reversed, to prevent issues with other OSes.

That would have the following advantages:
- No issues with other OSes

- Easier to move/symlink the affected files, by moving/symlinking the entire .linphone folder. Including the temporarily created .linphonerc.tmp file, which currently cannot be moved/symlinked, due to its temporary nature. (Also: any other temporary Linphone file a user might not be aware of would also be covered.)

- Easier AppArmor profile creation for Linphone. (No need to work around the issue that default AppArmor profile abstractions don't allow access to files matching .*rc in the user's home directory, which also includes .linphonerc.)

The disadvantage would be that on the next Linphone update users would need to re-do the configuration, due to the moved file location. Or to move the affected files into the new .linphone directory (and rename them by removing the leading dot). This could be explained in the release notes of the next version.

What do you think?

Thanks in advance!


On 28/07/15 11:54, Gautier Pelloux-Prayer wrote:

Indeed you are right symlinks should not be overridden. I made a tentative of 
patch in linphone master:

6ce479b 2015-07-28 11:48:32 +0200 Gautier Pelloux-Prayer  lpconfig.c: when 
reading linphonerc, we must follow symlinks

This will probably break some other OS but the idea is there ;-). If you can 
compile it, let me know if it's working as expected for you. Otherwise, it will 
be ready for next release which is not planned yet.


Gautier Pelloux-Prayer
Software Engineer @ Belledonne Communications

On 24 Jul 2015, at 04:41, address@hidden wrote:

Dear developers,

There is the following bug in recent version(s) of Linphone on Linux: If one 
moves the /home/[username]/.linphonerc file to a different location and 
replaces it with a soft link instead, the link gets overwritten with the actual 
file when Linphone starts.

I don't know when it started, just that it was not there in around April 
versions and is present now.

Test procedure:
1. Make sure that Linphone is closed completely (i.e. it's not present in the 
task bar)
2. Move both, /home/[username]/.linphonerc and 
/home/[username]/.linphone-history.db to a different drive (with a different 
file system) and place (soft) links to them in the original location.
3. Start Linphone (and let it sign into a previously configured SIP account)

Expected results:
3. Both links stay being links

Actual results:
3. /home/[username]/.linphone-history.db stays being a link, while 
/home/[username]/.linphonerc is overwritten with the actual file.

Note: This may have privacy/security implications if, e.g., the actual files 
(containing account names and passwords, etc.) had been moved to, e.g. an 
encrypted drive, but then re-appear in the unencrypted home directory again, in 
plain text - possibly without the user noticing.

Linphone 3.8.5, as provided by ppa:linphone/release; Linux Mint 17.1 (based on 
Ubuntu 14.04 Trusty), 64 bit.

Kind regards,


Linphone-users mailing list

Linphone-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]