Re: access rights in /sbin and /bin [Update]
The Wednesday 10 December 2008 07:04:50 [EMAIL PROTECTED], you wrote : On Mon, Dec 08, 2008 at 10:33:02AM -0500, Lennart Sorensen wrote: On Sun, Dec 07, 2008 at 04:11:04PM +0100, Hans-J. Ullrich wrote: thanks for the list. I checked and found out, that a lot of binaries in /sbin got permissions to rwxr-xr-- (root:root), but they should have rwxrwxr-x. I wondered, as I never changed the rights manually in the past and I am sure, I have not been hacked. So there is only one explanation: an applicatiopn must have changed it. Does someone know, which application is changing rights of binaries below /sbin ? I suppose, it is either bastille (which I installed and deinstalled a long time ago) or selinux (which i still installed). Please, which manual did i miss to read ??? So far the only thing I have ever seen that causes that is silly people who mess with the umask of the root user (which causes dpkg to make lots of mistakes). Perhaps dpkg shouldn't rely on the umask of the root user? Perhaps is should set it itself? Could this be considered a dpkg bug? It sounds reasonable indeed that dpkg don't rely on root umask. I don't want root to have a umask of 022 because usually I don't want users to read root file by default. Even if most of the time it's not a security issue, I don't want these file to be readable by users by default in case I forget to restrict rights of sensitive files. Furthermore, AFAIK files in /bin, /sbin and other bin directories aren't created, they are untared so that rights of these files are rights they have when tared by the debian maintener of the package. -- hendrik So if you ever set a umask for your root user, well don't and reinstall every affected package to fix the permissions. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Greetings, Thomas Preud'homme -- Why debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
Re: access rights in /sbin and /bin [Update]
The Tuesday 09 December 2008 14:38:40 Hans-J. Ullrich, you wrote : Am Dienstag, 9. Dezember 2008 schrieb Thomas Preud'homme: The Wednesday 10 December 2008 07:04:50 [EMAIL PROTECTED], you wrote : On Mon, Dec 08, 2008 at 10:33:02AM -0500, Lennart Sorensen wrote: On Sun, Dec 07, 2008 at 04:11:04PM +0100, Hans-J. Ullrich wrote: thanks for the list. I checked and found out, that a lot of binaries in /sbin got permissions to rwxr-xr-- (root:root), but they should have rwxrwxr-x. I wondered, as I never changed the rights manually in the past and I am sure, I have not been hacked. So there is only one explanation: an applicatiopn must have changed it. Does someone know, which application is changing rights of binaries below /sbin ? I suppose, it is either bastille (which I installed and deinstalled a long time ago) or selinux (which i still installed). Please, which manual did i miss to read ??? So far the only thing I have ever seen that causes that is silly people who mess with the umask of the root user (which causes dpkg to make lots of mistakes). Perhaps dpkg shouldn't rely on the umask of the root user? Perhaps is should set it itself? Could this be considered a dpkg bug? It sounds reasonable indeed that dpkg don't rely on root umask. I don't want root to have a umask of 022 because usually I don't want users to read root file by default. Even if most of the time it's not a security issue, I don't want these file to be readable by users by default in case I forget to restrict rights of sensitive files. Furthermore, AFAIK files in /bin, /sbin and other bin directories aren't created, they are untared so that rights of these files are rights they have when tared by the debian maintener of the package. Hmm, so if this is really the way, packages are installed, then I should always report to the maintainer of the package. On the other hand, I had some problems with the package eject. The installed binary got rwxr--r-- ( with owners root:root), but in the package itself it got rwxr-xr-x (root:root). I'm almost sure of what I said. For example I installed nicotine recently and my root umask is 027 but /usr/bin/nicotine is 755 so the umask is not used. I think umask is used in package installation only for files created by package scripts (postrm, prerm, etc.) When I reinstalled it, the permissions did not change. Then I deinstalled it completely and reinstalled it again. Now it got the correct permissions: rwxr-xr-x ! So far, so well. But after an upgrade some weeks later, the permissions were wrong again (set as before). I could not explain that to myself, but I could verify this behaviour. Lots of other binaries were showing the same effects (for example the kde screensaver suddenly could not have been unlocked any more, as the sticky bit was missing). So, if I would understand, how is and who is setting the permissions at upgrades or installing, I could find out, what is going wrong. Who knows it ? As you said before you must have a program that change these permissions later. It must have a program to monitor change on a file, like a permanent lsof which would say you which program did the modifications. Cheers Hans Regards, Thomas Preud'homme -- Why debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
Re: What is the best java for debian-amd64 ?
Tuesday 16 September 2008, Hans-J. Ullrich wrote : Hi all, as there are many java versions installable, what is the best one to use in amd64-systems ? What are the differences ? I saw gcj, gij, gdk, java. Can someone tell me, which should be used ? Ia ma very confused. Update-alternatives is giving me these choices: There are 8 alternatives which provide `java'. SelectionAlternative --- 1/usr/bin/gij-4.1 2/usr/lib/jvm/ia32-java-6-sun/jre/bin/java 3/usr/lib/jvm/java-gcj/jre/bin/java 4/usr/bin/gij-4.3 * 5/usr/lib/jvm/java-6-sun/jre/bin/java 6/usr/bin/gij-4.2 7/usr/lib/jvm/ia32-java-1.5.0-sun/jre/bin/java +8/usr/lib/jvm/java-6-openjdk/jre/bin/java Press enter to keep the default[*], or type selection number: I choose 5. What is this +-sign meaning ? It was your current alternative when you ran update-alternatives Questions, questions, questions Thanks for any help ! I think the two most important ones are the sun alternative because it is widely used and the openjdk which is the free sun JVM (v6 I think) + the free java libraries. It should replace the comming java 7 (where jvm + libraries is supposed to be free) in all distros I think. Not that I'm not completely sure of what I say. Kind regards Hans-J. Ullrich Regards, Thomas Preud'homme -- Why Debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
Re: What are these packages doing ?
Saturday 09 August 2008, Sandro Tosi wrote : What are these packages good for ? linux-image-amd64 linux-image-2.6-amd64 Are these meta-packages ? Or are these packages intend to let aptitude or apt-get automatically install the newest kernel-versions ? (If yes, then these are the packages I am looking for) for sure linux-image-2.6-amd64 lets you have always the latest 2.6 kernel for amd64 installed. apt-cache show it and check Depends line: it should have (if your machine is enough up-to-date) the version 2.6.25-2. And linux-image-amd64 as a dependance on the latest linux branch (here linux-image-2.6.amd64). If one day Linux jump to 2.8 version, then linux-image-amd64 dependance will be modified accordingly. Kindly, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi Regards, Thomas Preud'homme -- Why Debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
Re: Heavy bug in kde !
Wednesday 06 August 2008, Hans wrote : Dear maintainers, I discovered a heavy bug in kde. As I do not know, which part is responsible for it, I hope, someone other know and will send a bugreport for the package (or tell it to me, so that I can report it). --- Bug description: When you want to save your settings of kde (I mean your personal settings, the one, you save with the button save settings in the K-Menu), and you restart kde again, your settings are lost. Worse, you loose all your virtual desktops, there is only one left. All windows lost their frames (looks similar to the windows, when you start compiz) and it is no more possible to move windows ! Deleting ~/.kde or ./kde4 does NOT help ! So be warned: Get your old ~/.kde and ~/.kde4 as backup, otherwise you crash your whole kde !!! I could not find out, which part and files of KDE are responsible for this mess. It is the same, when you try this as the user root. You will crash kde of user root, too ! Again, if you want to find out what happens, be very, very careful and get your old kde-settings as backup. At the moment I can confirm this behaviour only on an amd64-system, as for normal users, for root and as well as for newly added users. - If you know, please send this bugreport to the right maintainer or give me an advice, whom I have to send best. Thank you very much ! regards Hans Look at these messages on debian-user : http://lists.debian.org/debian-user/2008/07/msg02501.html If I remember well I saw the solution in the last messages. Regards, Thomas Preud'homme -- Why Debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
Re: hal buggy ? [Update]
Le jeudi 31 juillet 2008, Hans-J. Ullrich a écrit : Hiho ! I managed to get hal running again! What did I do ? Just downgraded hal and hal-info to the version of debian/stable. Doing so, all start and stop scripts were changed (although I never changed them myself) = no success ! Then, upgraded to the version of testing = no success ! Last, upgraded to the version of sid = success ! Yeah ! So, it seems, there were some changes in the scripts (initscripts, start- and stop-scripts , whatever) between stable and sid, which might conflict with the binary of hal and hal-info. Probably the init scripts which became dependancy based, like in gentoo I think. I didn't knew the change was already done. Anyway, this message shall just be for your info. Problem is solved ! Cheers Hans Regards -- Why Debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
Re: EM64T compiling options?
The Tuesday 15 July 2008 14:39:41 Lennart Sorensen, You wrote : You almost certainly wouldn't. Very few people have any reason to write in assembly anymore. You might write a critical section of code in assembly, but all the glue ought to be in C, inluding anything to manage pthreads to do multiple threads, which is how you take advantage of multiple cores. You also can take a look at openmp which allow you to parallelize for loops and make easy synchronization. The support of openmp is included in latests gcc versions. -- Len Sorensen -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EM64T compiling options?
The Tuesday 15 July 2008 15:46:06 E. Rens, you wrote : The loop sharing looks exciting but openmp seems difficult to use too. Does openmp replace pthreads or work in combination ? AFAIK it use pthread to work but it create all necessary pthread at startup to avoid creating them at each loop parallelization. It should work properly with pthreads, it wouldn't be packaged with gcc if it wasn't the case. However I didn't test this combination. openmp is really simple to use, easier than programming the same thing with pthreads. You can see examples on wikipedia : http://en.wikipedia.org/wiki/OpenMP The purpose is to do simple parallelization. If you want to write an algorithm which needs modification to support multi-cores, you have to do it yourself with pthreads. Regards Emmanuel -- Thomas Preud'homme Why debian : http://www.debian.org/intro/why_debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
