Bug 69027 - finalized configuration item can be overriden by registrymodifications.xcu
Summary: finalized configuration item can be overriden by registrymodifications.xcu
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: target:4.3.0 target:4.2.0.1
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-06 11:10 UTC by Janos FARAGO
Modified: 2014-01-09 13:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janos FARAGO 2013-09-06 11:10:35 UTC
== Example ==

Let's create share\registry\data\finalized.xcu with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<oor:items xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="o" oor:finalized="true"><value>Example Corp.</value></prop></item>
</oor:items>

This sets and locks Tools - Options - LibreOffice - User Data - Company. When I open LibreOffice, I see Example Corp., and although I can modify the edit box, the setting is not saved, when I reopen the panel, Example Corp. is there. So far, so good.

Then close LibreOffice, and edit registrymodifications.xcu manually. Add an item:
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="o" oor:op="fuse"><value>MyCompany Ltd.</value></prop></item>

Open LibreOffice, and check Tools - Options - LibreOffice - User Data - Company, there will be MyCompany Ltd. And this setting is still locked, i.e. cannot be changed from the UI.

== Problem ==

User can override a finalized setting that is forced on her by company policy, because registrymodifications.xcu is writable by the user. Company name is only an example, presumably every finalized setting can be overridden, and it makes the feature useless.
Comment 1 Cor Nouws 2013-09-06 11:46:54 UTC
Hi Janos,
thanks for the report. Have you tested this with older versions too? (the report is against 4.2.0.0 master)

I recognise the behaviour, but never tested up to changing the registrymodifications.xcu manually.
Cor
Comment 2 Janos FARAGO 2013-09-06 11:53:19 UTC
(In reply to comment #1)
I work with master, mainly. But I've just tried and reproduced the problem with LibreOffice 3.5.4.
Comment 3 Stephan Bergmann 2013-09-06 16:12:23 UTC
indeed, XcuParser::handlePropValue (configmgr/source/xcuparser.cxx) does not care about state_.top().locked
Comment 4 Commit Notification 2013-12-09 11:56:56 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=93210ec3b3e7e773e998a3771136043748232f85

fdo#69027 check for state_.top().locked



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 5 Commit Notification 2013-12-09 12:17:53 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4fb12553f5f273058156026300a715326ec3da2f&h=libreoffice-4-2

fdo#69027 check for state_.top().locked


It will be available in LibreOffice 4.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 6 Andras Timar 2014-01-09 13:24:11 UTC
This has been fixed, actually.