Issue 71807 - The OOo file picker doesn't respect Group Policy
Summary: The OOo file picker doesn't respect Group Policy
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: current
Hardware: PC Windows, all
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-11-21 11:36 UTC by tml
Modified: 2017-05-20 11:31 UTC (History)
2 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description tml 2006-11-21 11:36:09 UTC
It is possible to use Group Policy to prevent browsing of some drive letters
(and perhaps server shares?) in an Active Directory domain. OOo's own file
dialog doesn't respect such restrictions. It probably should. Some customer site
might feel strongly about OOo users being able to break "security" by using the
OOo file dialog. (Although, I guess it could be argued, that whatever security
one imagines comes from restricting the drives visible in the file open dialog,
and browseable in Windows Explorer, is false security...)

The system file picker on Windows obviously does respect Group Policy, as it
wraps the Microsoft file open dialog.
Comment 1 philipp.lohmann 2006-11-21 11:54:03 UTC
pl->fs: please have a look
Comment 2 tml 2006-11-22 17:23:26 UTC
I opened this issue because I am (in my copious spare time) the maintainer of
GTK+ on Windows, and a user complained that the GTK+ file chooser shows drives
that should be hidden. I then realized that the same probably goes for OOo's own
file picker, too.

Anyway, it seems that the code required to determine which drives should be
hidden is very simple: One just has to look at a DWORD value in the Registry,
which is a bitmask, one but per drive letter. See  That knowledge base article claims that
it applies to Win98 and NT4, but presumably they just haven't updated the
article text and it holds for current versions, too.

Yeah, drive letters are a kinda stone age concept... I don't know whether there
are other more modern ways to limit the browseability of network shares, or
mounted volumes. But anyway, as a first cut it would be nice to at least obey
the NoDrives setting.

How to integrate such a check in a clean way into the OOo OfficeFilePicker I
can't say. I could come up with a patch suggestion, unless you tell me you
aren't interested?
Comment 3 philipp.lohmann 2006-11-22 17:34:35 UTC
We're always interested in patches. However the file picker itself might be the
obvious but not necessarily the right choice since it is system agnostic. It
might be that the correct place to implement this would be the actual file layer
in the sal project or perhaps a registry layer (because the file picker uses UCB
services as far as i know which already can exclude some configured paths,
though configured not in the system registry but in OOo's registry). However I
think fs might have something to say on that.
Comment 4 Frank Schönheit 2006-11-22 20:56:18 UTC
fs->tml: thanks for the hints how to solve this, and thanks for the offering. Of
course there's no reason why we shouldn't be interested in a patch.

Unfortunately, as Philipp said, the file picker would be the wrong place. It
uses the UCB (universal content broker), and I think a patch should be therein -
in ucb/source/ucp/file, I suppose. I'm cc'ing abi here, I suppose he also has an

fs->abi: Would you agree that the file UCP is the proper place to respect the
hidden drives, or should this even be one layer below, in OSL?
Comment 5 tml 2006-11-22 21:39:37 UTC
The intent of this policy setting is not to prevent application code from
accessing some drives altogether. (The user who asked for this in the GTK+ file
picker said that their site prevents end-users from browsing their local C:
drives. I assume apps are still installed on local drives on that site by
sysadmins. It would be rather silly if apps could not access the local drive to
read their own data files, store temp files or whatnot. )

I guess the policy is more supposed to be just a "hint" to cooperating software
(like Explorer, and Microsoft's own file open dialog) to prevent unsophisticated
users from casually browsing "hidden" drives interactively.

I don't think it would be correct to block access to the "hidden" drives
altogether at lower levels in OOo. I suspect sysadmins on sites that use a
policy like this are well aware that determined users can circumvent it, for
instance by using VBA or whatever scripting in some app.

(Personally I think such a policy is then rather pointless and just false
security. But... some customer might think it is useful and perhaps then avoid
OOo because it provides a trivial way to get around the policy.)

Perhaps the OfficeFilePicker should call some optional functionailty in the UCP
like "prefixIsHiddenByPolicy" or whatever that would check if a URI is in a
subtree hidden in some platform-dependent way. On Win32 this would be done by
checking the NoDrives value.
Comment 6 Frank Schönheit 2006-11-22 21:58:33 UTC
This in fact doesn't sound as if it belongs into OSL, or even only UCB. Seems to
be a mere UI "feature", somewhat complementary to

Accepting, Targeting. I don't consider this important enought for 2.x - but
would accept and integrate a patch, of course ;)
Comment 7 Marcus 2017-05-20 11:31:24 UTC
Reset assigne to the default "".