That doesn't go far enough for some. They want the license to terminate as soon as the other party brings action against the copyright holder for any patent infringements whatsoever.
Of course, even this can't defend against patent hoarding thinktank companies.
The kind of clauses being speculated about are those such as, (very broadly) you may not remove the software's ability to provide a link to the source code to the end user.
Copyright law reserves the rights of distribution and modification to the copyright holder. So the copyright holder may grant you the right to distribute and modify the software as long as you don't remove the source code distribution functionality.
"potentially forced"? Please. The only people "forced" into using this clause are those who don't read the license before releasing their software under it. They are forced, only by their own stupidity.
When the article meantioned "Linux" it meant "GNU/Linux" as opposed to Linux-the-kernel. A log of GNU/Linux software uses the GPL with the upgrade clause--hence it is important.
Oops, I just realised what you meant. I would like to amend my original statement. Replace "chmod o-x perl" with "don't let them run perl". If I actually wanted to do this on a machine, I guess I would chroot the user away, or deploy SELinux or grsecurity, so that they could only access the programs they are allowed to.
When you are dealing with security, semantics are extremely important! It is important for an administrator to understand exactly what happens, what is being executed when a shell/perl/python/etc script is "run".
An administrator who does not understand the purpose/scope and usr/effect of the noexec mount option may misuse it in exactly the way you demonstrated.
Indeed, but, as you so aptly illustrate, it's not. Your script example illustrates this aptly: make a perl script in/usr/local/sbin; chown it root:bin; chmod it go-x. Users can still execute the sucker.
The user can not execute the script. They can only execute perl. If you have a problem with them being able to run perl, then you must chmod o-x/usr/bin/perl.
Jesus Christ, I don't even have a Mac, and I have never heard of this 'pacifist' program. I just thought you might find that snippet of information useful, since you said that you couldn't drag the codec to your Library manually since it was a.pkg file. Next time I won't bother.
"Try to install it on Linux and you realise the advantages of a commercial platform onto which you simply install binary application packages."
"Linux" is a kernel. As you can see from http://packages.debian.org/vlc, it isn't hard to apt-get install vlc. The VLC home page even has packages for many distributions, along with pretty little colourful icons.
Having said that, someone could write a plugin to display OpenDocument documents, just like any other browser plugin, although I would get annoyed that every time I clicked on a link to an OpenDocument file, I had to wait for OpenOffice.org to load...
Isn't Firefox just a third party program that makes GNU/Linux or Windows or your OS of choice work correctly? Ok so you might use Opera or some other browser... in which case, isn't $browser just a third party program that makes your computer work correctly?
The LSB specifies RPM as a distribution format. It does not mandate its use as a package manager. They could (should) have picked 'gzip compressed tar archive' for all I care. The point is that LSB software comes in a standard format that it is easy to install on any LSB compliant system. For example, on Debian (and derivatives), you do:
So what exactly is their explanation of why the SUSE admins were not alowed to use SUSE's equivalent of apt-get? And isn't SUSE 8 a bit long in the tooth anyway? But then I suppose I should expect this level of intellectual dishonesty from Microsoft.
Slashdot Mirror
That doesn't go far enough for some. They want the license to terminate as soon as the other party brings action against the copyright holder for any patent infringements whatsoever.
Of course, even this can't defend against patent hoarding thinktank companies.
It doesn't have to turn into an EULA.
The kind of clauses being speculated about are those such as, (very broadly) you may not remove the software's ability to provide a link to the source code to the end user.
Copyright law reserves the rights of distribution and modification to the copyright holder. So the copyright holder may grant you the right to distribute and modify the software as long as you don't remove the source code distribution functionality.
"potentially forced"? Please. The only people "forced" into using this clause are those who don't read the license before releasing their software under it. They are forced, only by their own stupidity.
When the article meantioned "Linux" it meant "GNU/Linux" as opposed to Linux-the-kernel. A log of GNU/Linux software uses the GPL with the upgrade clause--hence it is important.
I don't understand the difference between the recordings being available only as streams, and for downloading.
IIRC, 2.0 has been stable/recommended over the 1.x versions since 2001.
I buggered it up. It should be: perl <(cat /mnt/unexecutables/evil.pl)
It's called Process Substitution. It's a great way to avoid the use of temporary files in shell scripts.
And of course perl (cat /mnt/unexecutables/evil.pl).
:)
So the real solution is, again, if you don't want a user to be able to run a program, don't give him a shell.
Oh hold on a minute...
/usr/bin/perl /lib/ld-linux.so.2 /usr/bin/perl ./usr/bin/perl: error while loading shared libraries: /usr/bin/perl: cannot open shared object file: Permission denied
:)
# chmod o-rx
#
I knew I'd overlooked something!
(Goddamnit, why won't Slashdot let me break lines where I want to...)
It probably wouldn't be too hard to patch Perl, Python and others to refuse to read a script from a filesystem mounted with noexec.
Oops, I just realised what you meant. I would like to amend my original statement. Replace "chmod o-x perl" with "don't let them run perl". If I actually wanted to do this on a machine, I guess I would chroot the user away, or deploy SELinux or grsecurity, so that they could only access the programs they are allowed to.
When you are dealing with security, semantics are extremely important! It is important for an administrator to understand exactly what happens, what is being executed when a shell/perl/python/etc script is "run".
An administrator who does not understand the purpose/scope and usr/effect of the noexec mount option may misuse it in exactly the way you demonstrated.
No, you can't, as discussed before:
/mnt/ -o noexec /bin/bash /mnt /mnt/bash /mnt/bash: permission denied /lib/ld-linux.so.2 /mnt/bash /mnt/bash: error while loading shared libraries: /mnt/bash: failed to map segment from shared object: Operation not permitted
# mount -t tmpfs none
# cp
#
bash:
#
.
If you use TLS to secure your IMAP connection, then you wouldn't have to trust your ISP.
The user can not execute the script. They can only execute perl. If you have a problem with them being able to run perl, then you must chmod o-x
Jesus Christ, I don't even have a Mac, and I have never heard of this 'pacifist' program. I just thought you might find that snippet of information useful, since you said that you couldn't drag the codec to your Library manually since it was a .pkg file. Next time I won't bother.
Right (or control)-click on the .pkg file and choose 'Show Package Contents' from the contextual menu.
They are just cells. Who gives a crap?
No offence, but your comment reminded me of this Dilbert strip. :)
Having said that, someone could write a plugin to display OpenDocument documents, just like any other browser plugin, although I would get annoyed that every time I clicked on a link to an OpenDocument file, I had to wait for OpenOffice.org to load...
Isn't Firefox just a third party program that makes GNU/Linux or Windows or your OS of choice work correctly? Ok so you might use Opera or some other browser... in which case, isn't $browser just a third party program that makes your computer work correctly?
Package your software into an LSB RPM. Anyone (using an LSB compliant distribution) can then install it.
:) And it works pretty well.
If you are using libraries that the LSB does not specify, build private copies and distribute them in your package.
Good lord! That's pretty much exactly how software distribution works on Windows!
The LSB specifies RPM as a distribution format. It does not mandate its use as a package manager. They could (should) have picked 'gzip compressed tar archive' for all I care. The point is that LSB software comes in a standard format that it is easy to install on any LSB compliant system. For example, on Debian (and derivatives), you do:
alien --to-deb blah.rpm
dpkg --install blah.deb
You get the FCC to fine him $10,000 a day, and/or shut him down... :)
I always wondered about that thing. Do you just link your program with -lgc and get free garbage collection for no extra effort?
So what exactly is their explanation of why the SUSE admins were not alowed to use SUSE's equivalent of apt-get? And isn't SUSE 8 a bit long in the tooth anyway? But then I suppose I should expect this level of intellectual dishonesty from Microsoft.