BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Too much protection? Goto page 1, 2  Next          BorlandTalk.com Forum Index -> comp.lang.pascal.delphi.misc View previous topic :: View next topic   Author Message Ronald van der Pas Guest Posted: Wed Jan 04, 2006 7:42 pm    Post subject: Too much protection? Hi, Some administrators prevent users to write to the key: HKEY_LOCAL_MACHINESoftware in the registry. I sometimes have discussions with administrators that my application must be able to acces this key. Is it unreasonable to demand acces to this key? Or do you think it is a good security procedure to prevent this? Greetings, Ronald van der Pas The Netherlands Back to top Andreas Koch Guest Posted: Wed Jan 04, 2006 8:22 pm    Post subject: Re: Too much protection? Ronald van der Pas wrote: Quote: Some administrators prevent users to write to the key: HKEY_LOCAL_MACHINESoftware in the registry. I sometimes have discussions with administrators that my application must be able to acces this key. Is it unreasonable to demand acces to this key? Or do you think it is a good security procedure to prevent this? As far as i know, "good" software should *ONLY* write to the HKEY_CURRENT_USER branch when running. Limited users shouldn't be able to install software, and only installing software should write to HKEY_LOCAL_MACHINESoftware. I think there was some microsoft styleguide arround for this, but i can't find it now... Back to top Rob Kennedy Guest Posted: Wed Jan 04, 2006 9:54 pm    Post subject: Re: Too much protection? Ronald van der Pas wrote: Quote: Some administrators prevent users to write to the key: HKEY_LOCAL_MACHINESoftware in the registry. Not just _some_ administrators; any administrator who does nothing to the default Windows installation settings. Quote: I sometimes have discussions with administrators that my application must be able to acces this key. What settings do users of your software need to change that need to affect *all* other users of that software? Quote: Is it unreasonable to demand acces to this key? The *whole* key? Definitely! Arbitrary users should not be allowed to make system-wide changes to a shared computer. You might be able to compromise with the administrators and get write access to only your software's subkey. Any good installation tool should be able to configure the access permissions for you, so there would be no intervention necessary by the administrator. But before you do that, answer my question above. Quote: Or do you think it is a good security procedure to prevent this? Within that key is where Windows keeps track of which shell extensions are trusted -- which ones Explorer will allow itself to load. If everyone has write access to that list, then anyone can install any software and have it be activated unknowingly by anyone else on the system, including the administrator. Does that sound like a good security procedure to you? -- Rob Back to top Maarten Wiltink Guest Posted: Thu Jan 05, 2006 7:53 pm    Post subject: Re: Too much protection? "Crazy" <Crazy (AT) You (DOT) Must.Be.Crazy.pluto> wrote Quote: Call me Old-School or just plain antiquated, but personally I keep the hell out of the registry. It's a fragile and hopelessly ill-designed POS, in my opinion. ANYTHING I need to save, I write to a config file, in the software directly. This is a very common opinion. Where it comes from, I honestly don't know. I use the registry all the time and have never had any problems, except the one time in 1996 when I decided to clean it up and deleted everything under HKCR. As I know now, all my filetype associations and OLE information disappeared, but this did not crash Windows or any applications. Importing a colleague's HKCR hive solved any visible problems and caused no new ones (these _were_ simpler times). People call the registry fragile, but in my experience it isn't. I'd like to hear stories, but I promise no sympathy for those who blundered themselves ignorantly to ruin. That includes me in 1996. I find it peculiar that Object Pascal programmers, of all people, should find the registry ill-designed. It's hierarchical. It's strongly typed. It should match our thinking patterns _better_ than .ini files. To an intelligent human, the registry should be clearly an outgrowth of ..ini files. It's clearly the same thing, with typed values and nested sections added, and the new constraint that keys (value names) must be unique per section (key). I can live with that. Most often quoted is the fact that registry settings are pulled out of their natural habitat, in the filesystem near the installed application. First of all, this is the necessary outcome of a design decision: to have only one registry. But even more, the existence of that "natural habitat" is a fallacy. Near the application files is a natural place for configuration that applies to the application. But there can also be configuration that is specific to an installation, a site, a server, a client, or to a user. We had this discussion here once. If the registry is bad, how much worse are .ini files in the Windows directory? A Common Files directory? Do you prefer having to hunt through profiles? And what is the great advantage then? Groetjes, Maarten Wiltink Back to top Andreas Koch Guest Posted: Thu Jan 05, 2006 9:30 pm    Post subject: Re: Too much protection? Maarten Wiltink wrote: Quote: If the registry is bad, how much worse are .ini files in the Windows directory? A Common Files directory? Do you prefer having to hunt through profiles? And what is the great advantage then? I actually prefer applications with ALL files they need (including all non windows standard DLLs) in their own directory, so you can just copy that directory to another PC to install them. Well, with potential multiuser systems, its probably better having the personal configuration in %user%own files Back to top Hans-Peter Diettrich Guest Posted: Thu Jan 05, 2006 11:10 pm    Post subject: Re: Too much protection? Maarten Wiltink schrieb: Quote: Call me Old-School or just plain antiquated, but personally I keep the hell out of the registry. It's a fragile and hopelessly ill-designed POS, in my opinion. ANYTHING I need to save, I write to a config file, in the software directly. This is a very common opinion. Where it comes from, I honestly don't know. I use the registry all the time and have never had any problems... I don't want to encourage an useless flame war, about the registry or ini files. Both have the same essential problems, even if some people think that one solution were really better. From the system management viewpoint it's nicer to have .ini files for private application information, which can be easily removed from a system, without affecting the system or other applications. Then it's also a bit easier to maintain distinct backups of specific .ini files, which can be restored easily and safely after experiments. Distinct .ini files also *encourage* according documentation of the essential entries, possibly with a description of the user configurable entries. Perhaps I've missed something, but I feel a need for a detailed change log of the registry, which would allow to detect and undo changes, made by specific users or applications. Such a log could be provided easily for the registry, in the dedicated access functions, in contrast to .ini files, where it's much harder until impossible to track changes in the same detailed style. The registry is the better place for storing commonly used (shared) information, including user specific settings, so that any application will know where to look for such information. Unfortunately a central registry does not encourage nor require that applications write their informations into locations, which can be recognized as to which application they pertain. Quote: I find it peculiar that Object Pascal programmers, of all people, should find the registry ill-designed. It's hierarchical. It's strongly typed. It should match our thinking patterns _better_ than .ini files. To an intelligent human, the registry should be clearly an outgrowth of ..ini files. It's clearly the same thing, with typed values and nested sections added, and the new constraint that keys (value names) must be unique per section (key). I can live with that. I'd prefer an much more organized and restricted access to the registry, through dedicated methods for specific purposes, so that the user had not to bother with the verbose path name, under which the informations should be stored. Letting an application put data into arbitrary places in the registry, is as bad as letting an application put .ini files into arbitrary directories on any harddisk :-( Quote: Most often quoted is the fact that registry settings are pulled out of their natural habitat, in the filesystem near the installed application. First of all, this is the necessary outcome of a design decision: to have only one registry. But even more, the existence of that "natural habitat" is a fallacy. Near the application files is a natural place for configuration that applies to the application. But there can also be configuration that is specific to an installation, a site, a server, a client, or to a user. We had this discussion here once. ACK. Most hobby programmers have no idea about the woes of managing networks and multiple users. OTOH I'd appreciate that such programmers continue to use .ini files, so that a system administrator can easily recognize such applications and their related data, instead of having them written to the registry into inappropriate locations ;-) Quote: If the registry is bad, how much worse are .ini files in the Windows directory? A Common Files directory? Do you prefer having to hunt through profiles? And what is the great advantage then? The registry exists and should be used for it's designed purpose. Unfortunately we have to face inappropriately ported applications from the world outside Windows, which continue to store their information in configuration files. This is why I ask for dedicated system API methods for storing and retrieving configuration information, so that the applications can be written as the author *thinks* how they should behave, and the system can implement the storage and retrieval in it's own "natural" organization. Doesn't the registry already reflect a directory structure with /usr/local/ and similar locations, as are used in the Unix world? Has somebody ever tried to construct a map of corresponding locations, which could be used to port applications easily? I'd be interested in contributing to such a map, and also to write shareable code for better structured access to configuration information in the registry (and possibly outside the registry). The implementation could reside in a DLL or package, which can be provided or exchanged by the admin, to reflect his opinion about the storage of such information on his system(s). DoDi Back to top Bruce Roberts Guest Posted: Fri Jan 06, 2006 3:54 pm    Post subject: Re: Too much protection? "Hans-Peter Diettrich" <DrDiettrich (AT) nowhere (DOT) nix> wrote Quote: The registry is the better place for storing commonly used (shared) information, including user specific settings, so that any application will know where to look for such information. Unfortunately a central registry does not encourage nor require that applications write their informations into locations, which can be recognized as to which application they pertain. While I agree in general, I don't think that the registry is a terribly good place for user specific settings. Users can work on different workstations. More importantly, IMHO, its much easier to handle workstation upgrades by simply copying ini (or some other type of data) files, than having to export and import registry keys. I tend to use the registry sparingly and then only for workstation specific settings. Back to top Nicholas Sherlock Guest Posted: Sat Jan 07, 2006 1:58 am    Post subject: Re: Too much protection? Bruce Roberts wrote: Quote: "Hans-Peter Diettrich" <DrDiettrich (AT) nowhere (DOT) nix> wrote in message news:4263tmF1h49liU1 (AT) individual (DOT) net... The registry is the better place for storing commonly used (shared) information, including user specific settings, While I agree in general, I don't think that the registry is a terribly good place for user specific settings. Users can work on different workstations. Isn't this a vote /for/ using the registry? I have it in mind that some Windows product (Perhaps even something Microsoft) will mount the appropriate local user hive from a network drive when the user logs on. Cheers, Nicholas Sherlock Back to top Rob Kennedy Guest Posted: Sat Jan 07, 2006 2:40 am    Post subject: Re: Too much protection? Nicholas Sherlock wrote: Quote: Isn't this a vote /for/ using the registry? I have it in mind that some Windows product (Perhaps even something Microsoft) will mount the appropriate local user hive from a network drive when the user logs on. Yeah. That product is called Windows. I'm not sure what kind of setup is required for roaming profiles to work, though. -- Rob Back to top Andreas Koch Guest Posted: Sat Jan 07, 2006 11:43 am    Post subject: Re: Too much protection? Nicholas Sherlock wrote: Quote: Isn't this a vote /for/ using the registry? I have it in mind that some Windows product (Perhaps even something Microsoft) will mount the appropriate local user hive from a network drive when the user logs on. Roaming profiles, yes. But usually that kind of setups also have a "home directory" on the network. Back to top Maarten Wiltink Guest Posted: Sat Jan 07, 2006 1:42 pm    Post subject: Re: Too much protection? "Rob Kennedy" <me3 (AT) privacy (DOT) net> wrote Quote: Nicholas Sherlock wrote: Isn't this a vote /for/ using the registry? I have it in mind that some Windows product (Perhaps even something Microsoft) will mount the appropriate local user hive from a network drive when the user logs on. Yeah. That product is called Windows. I'm not sure what kind of setup is required for roaming profiles to work, though. Nothing special. A domain. User accounts with the "profile path" filled in. Doesn't everybody have a domain at home? The network mapping to the home directory (as noted by Andreas) is on that very same tab in the account properties (Windows 2000). Groetjes, Maarten Wiltink Back to top Bruce Roberts Guest Posted: Mon Jan 09, 2006 1:12 am    Post subject: Re: Too much protection? "Maarten Wiltink" <maarten (AT) kittensandcats (DOT) net> wrote Quote: Nothing special. A domain. User accounts with the "profile path" filled in. Doesn't everybody have a domain at home? Is the question sarcasm? If not, its been my experience that many smaller networks, even in business, don't have domains. Setting up roaming profiles doesn't require a great degree of expertise, but it does require some. Back to top Bruce Roberts Guest Posted: Mon Jan 09, 2006 1:14 am    Post subject: Re: Too much protection? "Nicholas Sherlock" <N.sherlock (AT) gmail (DOT) com> wrote Quote: Isn't this a vote /for/ using the registry? I have it in mind that some Windows product (Perhaps even something Microsoft) will mount the appropriate local user hive from a network drive when the user logs on. If the user group has fairly homogenus computing environments. And, if they all use roaming profiles, then yes. But like many design and coding decisions, one often has to go with the worst case scenario which is no. Back to top Marco van de Voort Guest Posted: Mon Jan 09, 2006 7:44 am    Post subject: Re: Too much protection? On 2006-01-07, Nicholas Sherlock <N.sherlock (AT) gmail (DOT) com> wrote: Quote: Bruce Roberts wrote: "Hans-Peter Diettrich" <DrDiettrich (AT) nowhere (DOT) nix> wrote in message news:4263tmF1h49liU1 (AT) individual (DOT) net... The registry is the better place for storing commonly used (shared) information, including user specific settings, While I agree in general, I don't think that the registry is a terribly good place for user specific settings. Users can work on different workstations. Isn't this a vote /for/ using the registry? I have it in mind that some Windows product (Perhaps even something Microsoft) will mount the appropriate local user hive from a network drive when the user logs on. So then you have to _fully_ login, and not just access a share. Extra requirements don't make an option more favourable ;-) Back to top Maarten Wiltink Guest Posted: Mon Jan 09, 2006 12:36 pm    Post subject: Re: Too much protection? "Bruce Roberts" <dontsendtober (AT) pleaseatbancoems (DOT) com> wrote Quote: "Maarten Wiltink" <maarten (AT) kittensandcats (DOT) net> wrote in message news:43bfc600$0$11063$e4fe514c (AT) news (DOT) xs4all.nl... <what's required for synchronised HKCU hives?> Quote: Nothing special. A domain. User accounts with the "profile path" filled in. Doesn't everybody have a domain at home? Is the question sarcasm? If not, its been my experience that many smaller networks, even in business, don't have domains. Partly. I suffer from a level of paranoia on the high side of healthy. The setup in my attic is fairly complex. Not everybody has more servers than workstations, and more workstations than inhabitants. Other people, even offices, may simply have Something That Works running production. Software houses probably do have different requirements than factory floors, or 3-person, 1.8-FTE, 2-PC administrative cubbyholes. But I would not even consider setting up an office where people don't have to login. Groetjes, Maarten Wiltink Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> comp.lang.pascal.delphi.misc All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.