Version: 0.9.0 (using KDE 3.3.0, SuSE) Compiler: gcc version 3.3.3 (SuSE Linux) OS: Linux (i686) release 2.6.5-7.104-default I was really excited when I discovered in KDE 3.1 or 3.2 that Kopete had a web presence plugin. At the time both the plugin and Kopete's handling of away messages was too broken to use, but now in KDE 3.3 I noticed that the away message handling is much better so I can actually use it for my own purposes. The web presence plugin, however, has a major problem: Apparently, it will not update an existing file, it first must delete the file (and with it the permissions) then it writes a new file that is readable only to me. When I set the directory permissions such that only root could delete but anyone could write to the file, I got an error from the plugin.
is this bug still valid for you ? I don't understand what really the pb is!
Yes, the web presence plug-in is still useless in Kopete 0.10 (Using KDE 3.4.0 Level "b"...) I am the only person who can read the file, which means that I can't serve it publically on the web. the permissions need to be 644 instead of 600
ok i have understood. $ ll total 4 -rw-rw-r-- 1 neoclust neoclust 774 mai 12 13:35 test.html i don't see any problem for me without modify and i have put the file on my personnal website ==> can read from an other pc
That's very interesting... I wonder what the difference is between our systems. Anyway, the plug-in itself should either make sure the permissions are good or not change them ever (as long as it can write to the file itself)
i'd say check the umask of the two systems to see if they differ.
How do I check/adjust that? I've tried looking it up before but have not had any luck
it is still valid for you ?
Yes.
I have tested this bug and everything seems to be OK. For the testing I created a directory as root. Then added file 'status'. Added permissions to be able to write to/rewrite(without changing permissions) this file. Plugin have successfully updated 'status' file. Commands: $ su # mkdir status_dir # cd status_dir # > status # chmod o+w status # exit $ Then playing with Kopete changing statuses. File is successfully updated. Hope I'll get some feedback despite it was 3 years ago ))
This still repros in Kopete 0.12.7 (KDE 3.5.10) on Kubuntu Hardy x86-64 I have of course given up on using Kopete for this (or any other) purpose in the years since I filed this. Still, it seems like it would be trivial to fix.
Sorry, one thing I forgot to mention: I did not test Roman's workaround - it probably does work, but it's beside the point, and it's a potential security risk: I don't want any world writable files on my webserver, an attacker should at least need to authenticate as me.
Ok, $ su # mkdir status_dir # cd status_dir # > status # chown david:group status # chmod o-rwx status # cd .. # chmod -R 0770 status_dir After this manipulations you have foder status_dir. Any user cannot create/delete files in this directory. However, user david do can change file status or overwrite it. For the test above plugin works... If I misunderstood you, can you please provide step-by-step actions which lead to error you are talking about? Thanks.
I don't understand your instructions: > $ su > # mkdir status_dir > # cd status_dir > # > status > # chown david:group status Ok. > # chmod o-rwx status You are removing the read permission. The entire problem is that the file does not have read permission for anyone but me > # cd .. > # chmod -R 0770 status_dir That will set the status file to 770 as well, and is again not helpful. Apache needs to be able to read the file, which it can't do unless the permissions include reading for Other. Assuming you mean 775... "An error occurred when uploading your presence page" because now Kopete can't write to the directory which is owned by root. What do you mean "Any user cannot create/delete files in this directory."? Not only is that not the case, but I wouldn't want it to be! When you say that "For the test above plugin works" are you sure it is writing to the location that you are creating above? If I change the ownership of the dir back to me, then as usual Kopete can write to it, and in doing so unsets the permission on the file back to 600.
Oh, sorry, I just noticed the 'not' in "Any user cannot create/delete files" - which is true, and also prevents the plugin from working.
>Assuming you mean 775... Yes I meant 1775 :) sorry. So, assuming NOBODY CAN create any file in the directory except root, and assuming NOBODY CAN delete any file, BUT the user (NOT root, but user, THAT LAUNCHED Kopete) CAN write to it - then everything works for me. Plugin does not creates the file, it OVERWRITES it which ok with such permissions. However, I must admit that I'm using KDE 4.2.1. I checked the code of KDE 3.5.10 - it looks the same. So I dont think that version of KDE really matters. Have if you any possibility to reproduce it with KDE 4.x it would be nice.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!