It was supposed to stop hundreds of years ago. But given the 20th century acceptance of large gifts from mafia dons to build churches in their neighborhoods, they're still selling absolution, even if it's occurring after the sin now, not before.
Steve Hassan, a fascinating author, describes the difference between cult and religion rather well. His work discusses the focus on a charismatic leader, the isolation from family and community, the deceptions about beliefs, the hypnotic techniques often used, and various layers used to surround the central leader and dogma and encourage each member to enter each layer by discarding more and more of their free will, their sense of self, and usually their money as they enter further.
Scientology started out as _neither_ religion or cult. It started out as a psychobabble pyramid scheme, and only started wearing priest-like collars and claiming religious status after the FDA found their claims of medical and psychological treatment to be fraudulent and blocked them from publishing such claims. It helps to be old enough to remember them before they claimed religious status, and the switch was very sudden.
But it also helps to remember that the Catholic Church used to sell "indulgences", forgiveness for a sin purchased before committing the sin. That helped create the Lutheran Church when Martin Luther got upset about it: so let's not pretend that this merely happens for cults, or is a new problem.
Oh, dear. I'm having real difficulty parsing some of your sentences. For example, "The OS servers are located then as well to the kernel space like on the user space." This doesn't really parse well in English.
If you write it in your native language, perhaps someone here can translate it well for you? It does sound like you have interesting things to say.
Saying GNU/Linux is more like saying "they speak American English", rather than saying "they speak American". It's actually more complete of a description, and clears up some confusion.
> >Then stop plugging your brand-new Blackberry into a USB v1.1 port.
Nice try. As the confirmation of several other posters shows, it's a problem for several other devices. And no, it's not restricted to a problem with USB 1.1 ports.
Oh, I'm sure the USB device _sends_ the juice: USB specs are well known and maximum voltages and currents cannot be normally exceeded with just software. No, the device is not _accepting_ the juice, probably as part of its need for quick-charge controller cleverness.
Not all phones will recharge this way without extra work. A co-worker and I just had a look at his new Blackberry, which refused to charge from his laptop unless proprietary software was also installed, and it refused to work with a discharged battery until at least 10 minutes after he first reconnected power and it had recharged the battery somewhat. Every other phone or portable device I've worked with worked _immediately_ after providing external power.
Standards are helpful, and I'd love to see a drop in the number of stupid adapters on the shelves of hardware stores and Staples, but amazingly stupid behavior like that Blackberry's can still be layered on top of good standards.
Very few of those do so _automatically_. For almost all such systems, you have to manually select password protected screen locking. Also "screen locking" for X servers does not prevent console access on the other virtual terminals, if you've left an active login on them, or simply killing the X session and grabbing the login shell of the user created their shell session manually.
Even more fun is available when careless laptop users run VPN sessions with such clients left unlocked, so anyone visiting their home or stealing their laptop can access the core of a poorly secured internal network where "we trust the people we work with" and they've refused to engage in effective internal security. The combination of NFS access and Subversion storing unencrypted passwords is a particularly egregious problem, as is the use of the 'keychain' SSH tool and its storgage of information about good targets to grab unlocked key access from in the settings recorded in $HOME/.keychain/.
Traveling data security, coupled with remote network access, is a very real problem only aggravated by people ignoring the risks.
It doesn't even take greed. One US vendor got an order for $10,000 of equipment, accepted the $20,000 check that was "erroneously" sent and agreed to refund the difference. By the time the $20,000 check bounced, the scammer was already long gone, the equipment was gone off the loading dock and the check for the difference was long cashed.
Given Nigeria's cash-poor economy, they probably forgot to bribe a policeman. Given that they 800 web sites, it was probably only a few servers or desktop machines. We can expect this scam to be in force until their upstream connectivity is willing to do _anything_ about such abuses.
Could your ownership settings have been messed up in CygWin, as far as/etc/passwd is concerned? Have you re-run 'mkpasswd -l' and 'mkgroup -l' for comparison of results?
Unattended access, and the requisite password saving, is an old and intriguing problem. It's one I've seen mishandled so many times throughout my career that I get somewhat upset to see people repeat it, and may sound like a Cassandra when I try to warn more experienced or aware people of what is consistently happening behind their backs in the real world. It's frightening in security terms.
Authentication of code is another old issue: I'd add checksums to your manifest to GPG sign, if I were in your situation. You clearly understand the usefulness of GPG authentication of code. I've not taken apart how git signs it, but git uses identifiers and checksums for the repositories in fascinating ways: I assume the checksum for the repository and its contents and its history up to that point are used to provide a key, which is GPG signed, associated with the contents of that particular tag.
No, the configs you posted do not allow anonymous access. They require authorized access via a password file (which the Subversion documentation does not mention how to manage), and an access configuration file (which you designate as svn-acl) which the administrator for Subversion has to figure out where to put, how to manage for multiple repositories, and other handwaving "just read the manual" steps which the manual does not, in fact, explain.
Examine syslog-ng, which can make a more sophisticated parsing of specific types of logs to specific targets, and set their permissions, with more resolution than syslog typically permits. It's feasible to have the same logs sent to multiple targets, and to make those logs accessible for various web clients.
This is not the "minimum" configuration. That's yet another authentication layer, with yet another set of passwords and rather poorly documented group access setttings.
The "minimum" configuration would be read-only, no password access, much like that provided by Sourceforge the Tigris Subversion repository itself. This is not directly documented in the Subversion documentation or FAQ, anywhere.
Your points are quite cogent: please allow me to add 3 details.
The 'svnserve -t' is usually added at the start of the authorized_keys: it's described in the Subversion FAQ at http://subversion.tigris.org/faq.html. Of course, that FAQ fails to set the '--tunnel-user=[username]' to get the logs recorded correctly. This kind of ignoring of necessary details is rampant among Subversion administrators and users, as we saw earlier with someone claiming 'svnadmin create' is all you need, and completely ignoring the handling of SSH keys.
If any user has write access to the bare files of the Subversion repository, they can modify _anything_. Logs, revision history, or files can all be modified with enough work. Logs, in particular, are easily modified by modifying the 'pre-revprop-change' hook script to enable easy modifications of the 'svn:log' property for a particular revision. This is potentially very nasty, but also helpful for correcting typos in logs or adding details to them after the fact.
Controlling the 'tags' space the way you describe is useful, but is unauthenticated. If I can edit the bare repository, I can modify the contents of your tags, pretty much without your knowledge unless you already have a checked out copy. Git has a very helpful option for GPG signing tags: this helps assure that the contents of a tag are, in fact, approved for release and helps prevent various man-in-the-middle attacks or deceitfully presented tags from being used to replace authorized code.
So, that's not just "svnadmin create" is it? You've left out of your message all the extra hand-created work to put all the users in a particular login group: since your setup is in-house, there is no opportunity to review it for other security issues or dangers. Please do not tell a nice "n00b" asking for sensible advice such an approach and leave out these very important parts.
And besides, this is normally done by using a single Subversion user account, not a set of accounts, and storing the SSH public keys in that user's "authorized_keys" file, with the svnserve command in the authorized_keys using the "--tunnel-user=[user]" option to get the Subversion changes attributed to the correct user. Yes, I've been through this before in a number of environments. This is workable, but pesky to set up the first time and to maintain as your list of users grows.
Now, git does this better. It provides and uses a restricted shell for the shared "git" user account, and there is a reasonably effective tool precisely for managing such keys called gitosis. I recommend it for people tired of writing the missing components for Subversion management.
GNA's system for handling Subversion access is unavailable to the Subversion community. It' sinhouse, and as near as I can tell, unpublished. So it's not useful for your own repository. A development and production system configuration tool shold be able to handle system-specific setings that are internal only. This may include SSH keys, password files, and unencrypted passwords (particularly for HTTPS and MySQL passwords, but for other features as well.) That means that GNA's apparently very useful system is unsuitable for the oritinal poster's development environment, and for any other environment, unless you want to go to quite a bit of extra work to encrypt such configuration handling for off-site storage. But encrypting it creates other problems, such as difficulties doing Subversion 'diff' commands.
Making programs suid is an _old_ technique, and it's historically very dangerous. It's far more dangerous if the suid program is suid root, true, but without a very careful code review, neither you nor I can be sure what other consequences of making Subversion tools suid might occur. It is therefore dangerous and unsuitable for a production environment.
For example, a few moments of thought already reveals a booby trap: checking out files with it could make them owned by the shared Subversion user, not the actual user. If the Subversion server itself is checking out its own configuration files, for this instance, setup files will suddenly be checked out as owned by 'svn', not 'root'. That means that any other user on the Subversion server, with the suid binary, could check out and _overwrite_ those system configuration files.
So GNA, in fact, is an off-site repository, not an in-house service? That's completely unsuitable, for fairly obvious security and availability reasons, for an in-house development and testing environment management approach. Building up that 'login group' and the tools to manage accounts for Subversion has no commonly available toolkit: it's all hand-done by different hosting sites.
Yes, I'm very familiar with SSH's authorized_keys options to restrict operations. It's useful: but it's not well supported for Subversion. The git community has a tool called 'gitosis' for just such key management, and a dedicated shell for such access: this is a much better approach than the svn approach, snce you don't have to build your own mangement tools yourself.
The potential adventures of making the svn binary suid, and the security adventures of trying to figure out which bets of a new Subversion repository need to be writable by that user and which should have access blocked, should be considered a fascinating adventure in programming. Making system programs suid is _not_ something that should be done casually.
You're making a reasonable assumption about admins, but one which in my observation is usually mistaken. If you look at the notes by 'TheRaven64, you see someone who apparently has either no klnowledge about how to protect their repository from random user access, or no desire to do so. The result is a security nightmare, and it's far too common in far too many environments.
There are some useful clients, such as the Gnome 'wallet', for storing the passwords more safely. But But you can't enforce the use of this, and it becomes increasingly likely as a site grows that some fool will store their passwords in $HOME/.subversion/auth because they use the built-in command-line clients which are _required_ for those wallets to work. And the original thread was for unattended system configuration deployment.
Even if such system configuration deployment is done via read-only HTTP access, where is the minimum configuration for this documented for Subversion?
Oh, no. Oh, dear god, no. You're giving all your svn+ssh users shell accounts on your Subversion server, givin them all write access to the full contents of your Subversion server, and _you expect this to be secure_? You do realize that if _any_ of them don't bother to use SSH keys, they're storing their shell account passwords in $HOME/.subversion/auth on any UNIX or Linux client machine they use, correct? And that they're vulnerable to umask problems of the creator of the subversion repository not granting them write privileges, without additional 'chmod' steps, and that setting universal write access means that anyone with shell access can deliberately or accidentally modify anything in the repository, right?
You are right in the "we trust everyone we work with" world, and it's incredibly dangerous in security and support terms.
That's interesting. Did they fix the uninstaller, which would would completely flush all copies of the OpenGL libraries, even the backed up ones originally with your OS distribution, if you ran the 'uninstall' script from a different version than had already been installed? That was quite nasty and made recovering your original, non-Nvidia enabled environment quite difficult.
viewgit seems to be a fork from viewvc. I've not dived into its history, but it's a very useful tool, much like viewvc is a very useful tool for browsing Subversion and CVS repositories without installing a client.
Slashdot Mirror
It was supposed to stop hundreds of years ago. But given the 20th century acceptance of large gifts from mafia dons to build churches in their neighborhoods, they're still selling absolution, even if it's occurring after the sin now, not before.
Steve Hassan, a fascinating author, describes the difference between cult and religion rather well. His work discusses the focus on a charismatic leader, the isolation from family and community, the deceptions about beliefs, the hypnotic techniques often used, and various layers used to surround the central leader and dogma and encourage each member to enter each layer by discarding more and more of their free will, their sense of self, and usually their money as they enter further.
It's fascinating material: the Wikipedia entry for him at http://en.wikipedia.org/wiki/Steve_Hassan contains links to his work.
Scientology started out as _neither_ religion or cult. It started out as a psychobabble pyramid scheme, and only started wearing priest-like collars and claiming religious status after the FDA found their claims of medical and psychological treatment to be fraudulent and blocked them from publishing such claims. It helps to be old enough to remember them before they claimed religious status, and the switch was very sudden.
But it also helps to remember that the Catholic Church used to sell "indulgences", forgiveness for a sin purchased before committing the sin. That helped create the Lutheran Church when Martin Luther got upset about it: so let's not pretend that this merely happens for cults, or is a new problem.
Oh, dear. I'm having real difficulty parsing some of your sentences. For example, "The OS servers are located then as well to the kernel space like on the user space." This doesn't really parse well in English.
If you write it in your native language, perhaps someone here can translate it well for you? It does sound like you have interesting things to say.
Saying GNU/Linux is more like saying "they speak American English", rather than saying "they speak American". It's actually more complete of a description, and clears up some confusion.
Paenblack wrote:
> >Then stop plugging your brand-new Blackberry into a USB v1.1 port.
Nice try. As the confirmation of several other posters shows, it's a problem for several other devices. And no, it's not restricted to a problem with USB 1.1 ports.
I, for one, get paid to avoid them and my employers from wasting valuable time, money, and bandwidth both from such errors.
Oh, I'm sure the USB device _sends_ the juice: USB specs are well known and maximum voltages and currents cannot be normally exceeded with just software. No, the device is not _accepting_ the juice, probably as part of its need for quick-charge controller cleverness.
Not all phones will recharge this way without extra work. A co-worker and I just had a look at his new Blackberry, which refused to charge from his laptop unless proprietary software was also installed, and it refused to work with a discharged battery until at least 10 minutes after he first reconnected power and it had recharged the battery somewhat. Every other phone or portable device I've worked with worked _immediately_ after providing external power.
Standards are helpful, and I'd love to see a drop in the number of stupid adapters on the shelves of hardware stores and Staples, but amazingly stupid behavior like that Blackberry's can still be layered on top of good standards.
And access to the corporate Wiki, with internal VPN security procedures, phone numbers, email addresses, and the org chart.
Very few of those do so _automatically_. For almost all such systems, you have to manually select password protected screen locking. Also "screen locking" for X servers does not prevent console access on the other virtual terminals, if you've left an active login on them, or simply killing the X session and grabbing the login shell of the user created their shell session manually.
Even more fun is available when careless laptop users run VPN sessions with such clients left unlocked, so anyone visiting their home or stealing their laptop can access the core of a poorly secured internal network where "we trust the people we work with" and they've refused to engage in effective internal security. The combination of NFS access and Subversion storing unencrypted passwords is a particularly egregious problem, as is the use of the 'keychain' SSH tool and its storgage of information about good targets to grab unlocked key access from in the settings recorded in $HOME/.keychain/.
Traveling data security, coupled with remote network access, is a very real problem only aggravated by people ignoring the risks.
It doesn't even take greed. One US vendor got an order for $10,000 of equipment, accepted the $20,000 check that was "erroneously" sent and agreed to refund the difference. By the time the $20,000 check bounced, the scammer was already long gone, the equipment was gone off the loading dock and the check for the difference was long cashed.
Given Nigeria's cash-poor economy, they probably forgot to bribe a policeman. Given that they 800 web sites, it was probably only a few servers or desktop machines. We can expect this scam to be in force until their upstream connectivity is willing to do _anything_ about such abuses.
Could your ownership settings have been messed up in CygWin, as far as /etc/passwd is concerned? Have you re-run 'mkpasswd -l' and 'mkgroup -l' for comparison of results?
Unattended access, and the requisite password saving, is an old and intriguing problem. It's one I've seen mishandled so many times throughout my career that I get somewhat upset to see people repeat it, and may sound like a Cassandra when I try to warn more experienced or aware people of what is consistently happening behind their backs in the real world. It's frightening in security terms.
Authentication of code is another old issue: I'd add checksums to your manifest to GPG sign, if I were in your situation. You clearly understand the usefulness of GPG authentication of code. I've not taken apart how git signs it, but git uses identifiers and checksums for the repositories in fascinating ways: I assume the checksum for the repository and its contents and its history up to that point are used to provide a key, which is GPG signed, associated with the contents of that particular tag.
No, the configs you posted do not allow anonymous access. They require authorized access via a password file (which the Subversion documentation does not mention how to manage), and an access configuration file (which you designate as svn-acl) which the administrator for Subversion has to figure out where to put, how to manage for multiple repositories, and other handwaving "just read the manual" steps which the manual does not, in fact, explain.
Examine syslog-ng, which can make a more sophisticated parsing of specific types of logs to specific targets, and set their permissions, with more resolution than syslog typically permits. It's feasible to have the same logs sent to multiple targets, and to make those logs accessible for various web clients.
This is not the "minimum" configuration. That's yet another authentication layer, with yet another set of passwords and rather poorly documented group access setttings.
The "minimum" configuration would be read-only, no password access, much like that provided by Sourceforge the Tigris Subversion repository itself. This is not directly documented in the Subversion documentation or FAQ, anywhere.
Your points are quite cogent: please allow me to add 3 details.
The 'svnserve -t' is usually added at the start of the authorized_keys: it's described in the Subversion FAQ at http://subversion.tigris.org/faq.html. Of course, that FAQ fails to set the '--tunnel-user=[username]' to get the logs recorded correctly. This kind of ignoring of necessary details is rampant among Subversion administrators and users, as we saw earlier with someone claiming 'svnadmin create' is all you need, and completely ignoring the handling of SSH keys.
If any user has write access to the bare files of the Subversion repository, they can modify _anything_. Logs, revision history, or files can all be modified with enough work. Logs, in particular, are easily modified by modifying the 'pre-revprop-change' hook script to enable easy modifications of the 'svn:log' property for a particular revision. This is potentially very nasty, but also helpful for correcting typos in logs or adding details to them after the fact.
Controlling the 'tags' space the way you describe is useful, but is unauthenticated. If I can edit the bare repository, I can modify the contents of your tags, pretty much without your knowledge unless you already have a checked out copy. Git has a very helpful option for GPG signing tags: this helps assure that the contents of a tag are, in fact, approved for release and helps prevent various man-in-the-middle attacks or deceitfully presented tags from being used to replace authorized code.
So, that's not just "svnadmin create" is it? You've left out of your message all the extra hand-created work to put all the users in a particular login group: since your setup is in-house, there is no opportunity to review it for other security issues or dangers. Please do not tell a nice "n00b" asking for sensible advice such an approach and leave out these very important parts.
And besides, this is normally done by using a single Subversion user account, not a set of accounts, and storing the SSH public keys in that user's "authorized_keys" file, with the svnserve command in the authorized_keys using the "--tunnel-user=[user]" option to get the Subversion changes attributed to the correct user. Yes, I've been through this before in a number of environments. This is workable, but pesky to set up the first time and to maintain as your list of users grows.
Now, git does this better. It provides and uses a restricted shell for the shared "git" user account, and there is a reasonably effective tool precisely for managing such keys called gitosis. I recommend it for people tired of writing the missing components for Subversion management.
Oh, dear. Let's try this carefully.
GNA's system for handling Subversion access is unavailable to the Subversion community. It' sinhouse, and as near as I can tell, unpublished. So it's not useful for your own repository. A development and production system configuration tool shold be able to handle system-specific setings that are internal only. This may include SSH keys, password files, and unencrypted passwords (particularly for HTTPS and MySQL passwords, but for other features as well.) That means that GNA's apparently very useful system is unsuitable for the oritinal poster's development environment, and for any other environment, unless you want to go to quite a bit of extra work to encrypt such configuration handling for off-site storage. But encrypting it creates other problems, such as difficulties doing Subversion 'diff' commands.
Making programs suid is an _old_ technique, and it's historically very dangerous. It's far more dangerous if the suid program is suid root, true, but without a very careful code review, neither you nor I can be sure what other consequences of making Subversion tools suid might occur. It is therefore dangerous and unsuitable for a production environment.
For example, a few moments of thought already reveals a booby trap: checking out files with it could make them owned by the shared Subversion user, not the actual user. If the Subversion server itself is checking out its own configuration files, for this instance, setup files will suddenly be checked out as owned by 'svn', not 'root'. That means that any other user on the Subversion server, with the suid binary, could check out and _overwrite_ those system configuration files.
So GNA, in fact, is an off-site repository, not an in-house service? That's completely unsuitable, for fairly obvious security and availability reasons, for an in-house development and testing environment management approach. Building up that 'login group' and the tools to manage accounts for Subversion has no commonly available toolkit: it's all hand-done by different hosting sites.
Yes, I'm very familiar with SSH's authorized_keys options to restrict operations. It's useful: but it's not well supported for Subversion. The git community has a tool called 'gitosis' for just such key management, and a dedicated shell for such access: this is a much better approach than the svn approach, snce you don't have to build your own mangement tools yourself.
The potential adventures of making the svn binary suid, and the security adventures of trying to figure out which bets of a new Subversion repository need to be writable by that user and which should have access blocked, should be considered a fascinating adventure in programming. Making system programs suid is _not_ something that should be done casually.
You're making a reasonable assumption about admins, but one which in my observation is usually mistaken. If you look at the notes by 'TheRaven64, you see someone who apparently has either no klnowledge about how to protect their repository from random user access, or no desire to do so. The result is a security nightmare, and it's far too common in far too many environments.
There are some useful clients, such as the Gnome 'wallet', for storing the passwords more safely. But But you can't enforce the use of this, and it becomes increasingly likely as a site grows that some fool will store their passwords in $HOME/.subversion/auth because they use the built-in command-line clients which are _required_ for those wallets to work. And the original thread was for unattended system configuration deployment.
Even if such system configuration deployment is done via read-only HTTP access, where is the minimum configuration for this documented for Subversion?
Oh, no. Oh, dear god, no. You're giving all your svn+ssh users shell accounts on your Subversion server, givin them all write access to the full contents of your Subversion server, and _you expect this to be secure_? You do realize that if _any_ of them don't bother to use SSH keys, they're storing their shell account passwords in $HOME/.subversion/auth on any UNIX or Linux client machine they use, correct? And that they're vulnerable to umask problems of the creator of the subversion repository not granting them write privileges, without additional 'chmod' steps, and that setting universal write access means that anyone with shell access can deliberately or accidentally modify anything in the repository, right?
You are right in the "we trust everyone we work with" world, and it's incredibly dangerous in security and support terms.
That's interesting. Did they fix the uninstaller, which would would completely flush all copies of the OpenGL libraries, even the backed up ones originally with your OS distribution, if you ran the 'uninstall' script from a different version than had already been installed? That was quite nasty and made recovering your original, non-Nvidia enabled environment quite difficult.
viewgit seems to be a fork from viewvc. I've not dived into its history, but it's a very useful tool, much like viewvc is a very useful tool for browsing Subversion and CVS repositories without installing a client.