summaryrefslogtreecommitdiffstats
path: root/build
diff options
context:
space:
mode:
authormark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-28 22:05:11 +0000
committermark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-11-28 22:05:11 +0000
commiteee9f55299e1223c156f1bcf86f557446009cc5e (patch)
tree5eb3b23a1754afca47a4a8e5b74078224d0c122e /build
parent110086c1a303bdcf3829a289efebef7e9378ab7b (diff)
downloadchromium_src-eee9f55299e1223c156f1bcf86f557446009cc5e.zip
chromium_src-eee9f55299e1223c156f1bcf86f557446009cc5e.tar.gz
chromium_src-eee9f55299e1223c156f1bcf86f557446009cc5e.tar.bz2
In-application Keystone ticket promotion.
The concept of "ticket promotion" is added to the application when Keystone is in use. Ticket promotion is used to turn a user Keystone ticket, which Chrome normally establishes when it launches, into a system Keystone ticket, after successful user authentication and authorization. Having a system Keystone with a system ticket means that updates are applied with root privileges instead of user privileges, essentially eliminating the possibility that a user will fall off of the auto-update train because they can read and execute but not write the application. Two principles of promotion apply: - An application on a user ticket NEEDS promotion if it determines that it doesn't have permission to write to itself. Being on a user ticket, an update attempt would fail. - An application on a user ticket WANTS promotion if it already NEEDS promotion. Additionally, if it is installed in a system-wide location such as /Applications, it will WANT promotion, even if it does not NEED it. If promotion is needed, an info bar will show up on launch requesting it. This info bar works similarly to the default browser info bar: it has a "don't bother me again" button, it will only show up after the first launch, it won't disappear on navigation if the navigation happens very quickly, and it won't show itself if another info bar is up. This means that if both the default browser info bar and the promotion info bar have a shot at showing, only one will win. In my experience, each wins about half of the time. If promotion is needed, the update UI in the About window will be hidden. Checking for updates and offering to apply them doesn't make much sense when the update won't be able to install successfully. All of the auto-update machinery is still working in the background, but the About window UI is hidden. If promotion is wanted, the About window will contain a new button allowing the user to enter promotion. This gives access to the same promotion routine as the promotion info bar. It can be used even from an administrative account that is able to update the application without promotion. It's intended to be used by the system administrator of the family without requiring them to switch to one of the kids' accounts. BUG=16360 TEST=Exhaustively, please. Review URL: http://codereview.chromium.org/437053 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33241 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'build')
-rw-r--r--build/common.gypi1
1 files changed, 1 insertions, 0 deletions
diff --git a/build/common.gypi b/build/common.gypi
index 424e3eb..cb71023 100644
--- a/build/common.gypi
+++ b/build/common.gypi
@@ -928,6 +928,7 @@
}],
['OS!="mac"', {
'sources/': [ ['exclude', '_(cocoa|mac)(_unittest)?\\.cc$'],
+ ['exclude', '/(cocoa|mac)/'],
['exclude', '\.mm$' ] ],
}],
['OS!="linux"', {