2009-11-05 26 views
5

Tôi đã có một số ứng dụng lâu đời được viết bằng Delphi vẫn tồn tại các cài đặt của họ trong sổ đăng ký. Tôi đã sử dụng HKEY_LOCAL_MACHINE cho các cài đặt 'cứng' như tùy chọn cấu hình và HKEY_CURRENT_USER cho thông tin 'mềm' như vị trí cửa sổ, danh sách MRU, v.v.Truy cập đăng ký ở chế độ không phải là quản trị viên

Bây giờ người dùng của tôi cho tôi biết ở chế độ không phải quản trị viên (người dùng chuẩn) các ứng dụng không hoạt động. Nhìn, tôi thấy rằng tôi không thể đọc một cài đặt được đưa vào HKEY_LOCAL_MACHINE khi ứng dụng ở chế độ quản trị.

Tùy chọn của tôi cho điều này là gì? Tôi biết rất ít về chế độ tiêu chuẩn và làm thế nào điều này ảnh hưởng đến quyền truy cập vào đăng ký ở tất cả. Bất kỳ thông tin nào được đánh giá cao.

+3

Mẹo: Bạn có thể muốn thử phát triển dưới tài khoản người dùng không có quyền lực. Có, đôi khi nó có thể hơi phiền toái một chút, nhưng bằng cách này bạn chắc chắn rằng "những điều bất ngờ" như bạn vừa mới gặp không làm bạn phải đối mặt. Đó là chính sách của công ty tại rất nhiều cửa hàng phát triển vì lý do chính đáng. –

+0

Ứng dụng của bạn sẽ hoạt động như thế nào trong Windows 2000 hoặc Windows XP như một người dùng chuẩn? Điều đó sẽ hướng dẫn bạn cách nó sẽ hoạt động trong Windows Vista hoặc Windows 7 như một người dùng chuẩn. –

Trả lời

14

Bạn có thể đọc từ HKLM với tư cách người dùng không phải quản trị viên; bạn không thể viết cho nó.

Sử dụng TRegistry.Create (KEY_READ) khi xây dựng nó và đặt RootKey thành HKLM.

var 
    Reg: TRegistry; 
begin 
    Reg := TRegistry.Create(KEY_READ) 
    try 
    Reg.RootKey := HKLM; 
    // Read value here 
    finally 
    Reg.Free; 
    end; 
end; 

Bạn cũng có thể sử dụng TRegistry.OpenKeyReadOnly() khi mở khóa đăng ký cụ thể; điều này giúp với quyền truy cập không quản trị vào các khu vực của sổ đăng ký.

+0

Bạn rất có thể không sử dụng chỉ đọc với mã hiện có của mình, đó là lý do mã không thành công. Sử dụng giải pháp của Ken nên sửa chữa nó cho bạn với những thay đổi ít nhất. –

+0

Đó là Ken tuyệt vời, chỉ là những gì tôi đang tìm kiếm. –

+1

@Brian: Vui vì tôi có thể giúp. Bạn có thể cũng muốn xem xét nhận xét của Paul-Jan cho câu hỏi của bạn; bạn có lẽ ít nhất nên thử nghiệm dưới một tài khoản không phải quản trị để nắm bắt những thứ này. MS bắt đầu thắt chặt mọi thứ (tự nguyện) với XP và đã thực thi nhiều hạn chế hơn kể từ khi phát hành Vista. –

0

Tùy chọn của bạn bao gồm (a) sử dụng tệp cấu hình INI/XML ở vị trí không yêu cầu quyền quản trị để truy cập miền).

Sự cố với tùy chọn a là thay đổi về sắp xếp thư mục giữa XP và Vista/W7. Tôi tin rằng Vista thắt chặt quyền truy cập vào CSIDL COMMON APPDATA - người dùng chuẩn không có viết acess nếu bộ nhớ phục vụ. Bạn có thể phải lưu trữ chúng trong thư mục của riêng bạn và tự mình sắp xếp quyền truy cập. Làm phiền.

Một vấn đề thú vị với tùy chọn b là hiện tại có rất ít công cụ nhỏ gọn được sử dụng trong môi trường công ty thu thập thông tin đăng ký và quyền truy cập "đúng" mà họ nghĩ là sai. Chúng tôi chưa gặp phải sự cố với khách hàng khi sử dụng chúng, nhưng chúng tôi biết rằng chúng tồn tại. Với hiệu suất của registry, chúng ta vẫn thích cách tiếp cận HKLM đã được sửa đổi và sẽ tiếp tục thực hiện nó trong tương lai gần.

+2

Vấn đề với tùy chọn B là nó vi phạm các vấn đề cơ bản về bảo mật Windows mà MS và các ứng dụng đã cố gắng triển khai kể từ khi giới thiệu XP và thực thi kể từ khi phát hành Vista. Phá vỡ chúng bằng cách thay đổi bảo mật trên registry chỉ là thực hành lập trình kém. Trình cài đặt của bạn sẽ chạy với tư cách quản trị viên và nếu cần, hãy ghi vào HKLM tại thời điểm đó. Ứng dụng của bạn sẽ chạy dưới dạng không phải quản trị viên và đọc từ (không viết thư) HKLM theo cách phù hợp khi cần. Các cách giải quyết hống hách như thay đổi an ninh chỉ là - hacks - cần tránh. An ninh Corp cũng ghét nó. –

+1

Kỳ lạ như nó có vẻ, tôi thực sự đồng ý với bạn. Tôi ước chúng tôi không phải làm điều này. Tất cả chúng ta đã được thiết lập để thay đổi để sử dụng một hệ thống tập tin cfg thông qua Common Appdata khi MS thay đổi các quy tắc truy cập cho điều đó trong Vista. Cho đến khi MS xác nhận rằng có các lớp hệ thống cần một ứng dụng ngữ cảnh không phải quản trị viên để thay đổi các cài đặt ảnh hưởng đến người dùng khác, chúng tôi bị kẹt. –

+0

@Bob: Họ có thể thừa nhận rằng sự lựa chọn không dễ dàng. Nó giống với vị trí của các tệp dữ liệu phổ biến. Không có vị trí nào có thể ghi được trên thế giới trong cài đặt mặc định có vẻ thực sự là ý tưởng hay khi bạn cân nhắc bảo mật. Một cài đặt chuẩn của một hệ thống giống Unix cũng không có vị trí như vậy. root/Quản trị viên có thể tự tạo một vị trí như vậy và có thể thiết lập hạn ngạch để ngăn người dùng độc hại lấp đầy toàn bộ không gian trống trên phân vùng/ổ đĩa. – mghie

1

Một tùy chọn mà tôi không ủng hộ nhưng sẽ đề cập đến, là cấp cho mọi người (hoặc một nhóm được xác định, v.v.) quyền truy cập khóa của bạn. Có nhiều cách khác nhau để thực hiện việc này và có mã trong JCL sẽ thực hiện hoặc bạn có thể sử dụng Regedit. Nhưng nếu bạn cho phép (với chi nhánh cụ thể của HKLM) thì nó sẽ hoạt động như bạn dự định.

+1

Đây là một ý tưởng rất tồi. Có những lý do khiến HKLM không thể ghi bởi người quản trị không; có thể viết ở đó là một vectơ tấn công cho vi-rút và phần mềm độc hại. Phá vỡ nó bởi vì bạn quá lười biếng để làm những điều đúng cách và kiểm tra chúng đúng cách chỉ là không phải là một ý tưởng tốt. –

+0

Tôi đồng ý - vì thế tôi không ủng hộ điều đó. Nhưng nếu đây là một ứng dụng nội bộ được sử dụng bởi ba người, thì có thể chấp nhận được. Và nó sẽ chỉ ảnh hưởng đến ứng dụng đó. Nó chắc chắn không phải là một cái gì đó để làm cho một ứng dụng mới, hoặc bất kỳ ứng dụng phân phối hàng loạt. Đối với họ, hãy làm đúng. – mj2008

2

Điều khác mà không ai được đề cập ở đây là vấn đề ảo hóa registry trên Vista & Win7 (ít nhất). Nó có thể không phải là một vấn đề trong kịch bản cụ thể của bạn, nhưng tôi nghĩ rằng tôi muốn đề cập đến nó anyway trong trường hợp nó có liên quan.
Ngay cả khi người dùng của bạn có quyền quản trị, nếu ứng dụng của bạn KHÔNG chạy "cao" trên Vista/Win7, ứng dụng của bạn sẽ không thể ghi vào khóa HKLM "thực" mà bạn nghĩ. Nó sẽ được đọc và ghi vào bản sao ảo của khóa HKLM thích hợp mà chỉ người dùng cụ thể mới thấy.
Bằng cách "nâng lên", tôi có nghĩa là bạn sẽ được nhắc nhở với một dấu nhắc UAC trên Vista/Win7. Chạy Regedit.exe ví dụ trên Vista/Win7, và bạn sẽ được nhắc nhở với một dấu nhắc UAC.
Nếu bạn đang sử dụng Vista/Win7, có thể đây là vấn đề bạn mô tả khi bạn nói không thể đọc khóa/giá trị được viết ở chế độ quản trị. Nếu vậy, điều này sẽ là do ứng dụng của bạn đã ở một số giai đoạn được viết bây giờ là một khóa/giá trị ảo hóa; bây giờ, ứng dụng của bạn sẽ chỉ thấy khóa/giá trị đó, ngay cả khi quản trị viên sửa đổi giá trị "thực".
Như những người khác đã nói, ứng dụng của bạn không nên cố gắng ghi vào HKLM. Nếu bạn cảm thấy nó cần phải viết để HKLM, sau đó trên Vista/Win7 lựa chọn của bạn (và các tùy chọn này có thể được thực hiện để làm việc tốt trên XP quá):

  • Thêm một biểu hiện để ứng dụng của bạn đòi hỏi phải có quyền quản trị cao theo điều này example.
  • Tách chức năng của bạn yêu cầu truy cập HKLM vào một thư viện COM riêng biệt và khởi tạo nó làm đối tượng COM được nâng cao và khi bạn cần. Điều này phức tạp hơn, nhưng là một cách hợp lý để cấu trúc lại chức năng hiện có.

Here Một câu hỏi SO khác giải quyết một số vấn đề này.

+0

Câu hỏi là về * đọc * từ HKLM, không phải bằng văn bản, vì vậy việc ảo hóa registry không áp dụng. –

+0

BTW, không downvoting vì, mặc dù nó không có gì để làm với các câu hỏi trong tầm tay, nó vẫn là thông tin tốt. –

+0

@Ken: đọc giữa các dòng của câu hỏi ban đầu, giải thích hợp lý của tôi là ứng dụng của OP sử dụng HKLM để lưu trữ cấu hình "sở thích", có nghĩa là đọc và viết. –

1

Từ góc độ nhà phát triển UAC của Windows có thể có vấn đề đối với một số phần trong ứng dụng Delphi của bạn, nếu ứng dụng không được quản trị viên điều hành. Một hoạt động như vậy là ghi vào cơ sở dữ liệu Registry.

Bạn phải "yêu cầu quyền quản trị" bằng cách tạo ra một ứng dụng file manifest ....

Windows Vista/7 - User Account Control

User Account Control là một thành phần bảo mật trong Windows Vista . UAC cho phép người dùng thực hiện các tác vụ phổ biến là người không phải là quản trị viên, được gọi là người dùng chuẩn trong Windows Vista và là quản trị viên mà không phải chuyển người dùng, đăng xuất hoặc sử dụng Run As. Để giúp ngăn phần mềm độc hại cài đặt âm thầm và gây nhiễm toàn bộ máy tính, Microsoft đã phát triển tính năng UAC.

Từ góc độ phát triển các tính năng UAC sau đây là quan trọng:

Tất cả quá trình được bắt đầu như là Người dùng chuẩn như mặc định Một Standard User không thể: file Thay đổi trong thư mục Program Files file Thay đổi trong Windows hoặc System32 thư mục Thay đổi registry dưới HKLM \ Software Thay đổi ngày máy địa phương và thời gian ... danh sách vẫn tiếp tục ...

lập trình chỉnh sửa registry để chạy ứng dụng Delphi của bạn trên Windows Sta rtup

Bằng cách lập trình chỉnh sửa Windows Registry, sử dụng đối tượng TRegistry, bạn có thể "tự động" bắt đầu chương trình bất cứ khi nào Windows khởi chạy. Thủ tục bạn có thể sử dụng để buộc "auto-run-trên-Windows-khởi động" cho các ứng dụng của bạn có thể trông giống như:

procedure RunOnStartup(const sCmdLine: string; bRunOnce: boolean = false; Remove: Boolean = false) ; 
var 
    sKey: string; 
    Section: string; 
const 
    ApplicationTitle = ”Your Application TITLE”; 
begin 
    if (bRunOnce) then 
    sKey := 'Once' 
    else 
    sKey := ''; 

    Section := 'Software\Microsoft\Windows\CurrentVersion\Run' + sKey + #0; 

    with TRegIniFile.Create('') do 
    try 
     RootKey := HKEY_LOCAL_MACHINE; 
     if Remove then 
     DeleteKey(Section, ApplicationTitle) 
     else 
     WriteString(Section, ApplicationTitle, sCmdLine) ; 
    finally 
     Free; 
    end; 
end; 

Trên Vista/7, nếu người dùng chạy các ứng dụng không có quyền quản trị các mã trên sẽ thất bại, do UAC!

Giả mạo UAC Quyền - Làm thế nào để Yêu Cầu Execution Level

Thậm chí nếu người dùng chạy các mã trên không phải là một admin, bạn có thể, như một nhà phát triển trang bị cho ứng dụng của bạn với một loại đặc biệt của tài nguyên nhúng: Ứng dụng tệp kê khai. Có tệp kê khai sẽ đảm bảo UAC của Vista sẽ cho phép mã của bạn thực thi.

Sau đây là các bước sau:

Tạo file XML với nội dung sau:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0] 
    <assemblyIdentity version="1.1.1.1" 
    processorArchitecture="X86" 
    name="YourApplicationExeName" 
    type="win32"/> 
    <description>elevate execution level</description> 
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2] 
    <security> 
    <requestedPrivileges> 
    <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> 
    </requestedPrivileges> 
    </security> 
    </trustInfo> 
</assembly> 

Tên file XML này như YourApplicationName.manifest Tạo một file văn bản với nội dung sau: 1 24 "YourApplicationName. manifest "

Đặt tên tệp văn bản này là YourApplicationName.RC bằng dòng lệnh thực hiện lệnh sau: brcc 32 YourApplicationName.RC -foYourApplicationName.REC

này sẽ tạo ra một file resource mới gọi YourApplicationName.REC

Sao chép tập tin YourApplicationName.REC này vào con đường tài nguyên của ứng dụng của bạn. Bao gồm tệp tài nguyên này vào ứng dụng DPR của bạn, như: {$R YourApplicationName.REC}

Cuối cùng, hãy tạo ứng dụng của bạn - bây giờ đã sẵn sàng để có quyền quản trị trên Windows Vista. Lưu ý 1: trong các bước trên, thay thế "YourApplicationExeName" bằng tên ứng dụng thực tế của bạn. Lưu ý 2: Các bước trên tạo tệp tài nguyên được lưu trữ bên trong tệp EXE của ứng dụng của bạn. Thông tin thêm về Tài nguyên trong các ứng dụng Delphi.

đọc thêm trong http://delphi.about.com/od/delphitips2009/qt/delphi-vista-registry-run-on-startup.htm

Các vấn đề liên quan