Bug 43172

*** Bug 64999 has been marked as a duplicate of this bug. ***

Bug is still present in KDE 3.2.1

Reported again at CeBIT. This is a very important issue for people using KDE over NFS for instance.

This problem might stand outside Konqueror. 
Apparently, all X apps launched through a KDE link (even non-KDE apps like OpenOffice) fail to use the correct umask when creating files, while behaving Ok when launched from a shell. 
Tested on KDE 3.1.4 and KDE 3.2.1 under Fedora Core 1. On both setups, the bug makes all KDE-launched apps create files with 644 permissions while umask 002 was set in the profile. Very annoying in collaborative environments. Could kdeinit be involved?

Addendum to comment #4
This comment definetely lies outside konqueror.
KDE obviously doesn't look up the "normal" startup files for X in this regard, i.e. you can't either add umask 002 to .xsession and friends.
The workaround I use at the moment (NFS-based mounts via the BSD-automounter) is to run a cronjob which changes permissions every three minutes, not the most elegant solution, but it helps!

Please reassign this bug accordingly, it is a serious KDE flaw.

KDE is not usable in enviroments where more than one person want to work together.

If this sounds strange to you please read about user private groups.
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-users-groups-private-groups.html

CVS commit by faure: 

Added setDefaultPermissions to make it possible to copy files without preserving
their permissions; the umask applies, instead. This is used when creating new files
from templates (RMB/"Create New") (kdebase/libkonq/knewmenu.cc).
CCMAIL: 43172-done@bugs.kde.org


  M +14 -2     job.cpp   1.368.2.9
  M +12 -0     jobclasses.h   1.133.2.2


--- kdelibs/kio/kio/job.cpp  #1.368.2.8:1.368.2.9
@@ -1873,4 +1873,7 @@ class CopyJob::CopyJobPrivate
 {
 public:
+    CopyJobPrivate() {
+        m_defaultPermissions = false;
+    }
     // This is the dest URL that was initially given to CopyJob
     // It is copied into m_dest, which can be changed for a given src URL
@@ -1880,4 +1883,6 @@ public:
     // The state info about that global dest
     CopyJob::DestinationState m_globalDestinationState;
+    // See setDefaultPermissions
+    bool m_defaultPermissions;
 };
 
@@ -2564,5 +2569,5 @@ void CopyJob::createNextDir()
     {
         // Create the directory - with default permissions so that we can put files into it
-        // TODO : change permissions once all is finished
+        // TODO : change permissions once all is finished; but for stuff coming from CDROM it sucks...
         KIO::SimpleJob *newjob = KIO::mkdir( udir, -1 );
         Scheduler::scheduleJob(newjob);
@@ -2958,5 +2963,7 @@ void CopyJob::copyNextFile()
             // Otherwise, files downloaded from HTTP end up with -r--r--r--
             bool remoteSource = !KProtocolInfo::supportsListing((*it).uSource);
-            int permissions = ( remoteSource && (*it).uDest.isLocalFile() ) ? -1 : (*it).permissions;
+            int permissions = (*it).permissions;
+            if ( d->m_defaultPermissions || ( remoteSource && (*it).uDest.isLocalFile() ) )
+                permissions = -1;
             KIO::FileCopyJob * copyJob = KIO::file_copy( (*it).uSource, (*it).uDest, permissions, bOverwrite, false, false/*no GUI*/ );
             copyJob->setParentJob( this ); // in case of rename dialog
@@ -3236,4 +3243,9 @@ void CopyJob::slotResult( Job *job )
 }
 
+void KIO::CopyJob::setDefaultPermissions( bool b )
+{
+    d->m_defaultPermissions = b;
+}
+
 CopyJob *KIO::copy(const KURL& src, const KURL& dest, bool showProgressInfo )
 {

--- kdelibs/kio/kio/jobclasses.h  #1.133.2.1:1.133.2.2
@@ -1292,4 +1292,16 @@ namespace KIO {
         KURL destURL() const { return m_dest; }
 
+        /**
+         * By default the permissions of the copied files will be those of the source files.
+         *
+         * But when copying "template" files to "new" files, people prefer the umask
+         * to apply, rather than the template's permissions.
+         * For that case, call setDefaultPermissions(true)
+         *
+         * TODO KDE4: consider adding this as bool to copy/copyAs?
+         * @since 3.3
+         */
+        void setDefaultPermissions( bool b );
+
     signals:
 

On Tuesday 11 May 2004 10:05, Thorsten Raff wrote:
> Dear David,
> 
> thank you very much for the fix. Since I am not familiar with the KDE
> sourcecode I have an additional question: Does the fix alter the standard way
> in which KDE creates new files, i.e. will every program invoked  under KDE
> use this function or does only a subset of programs use this interface?
The fix only affects RMB / Create New in konqueror and kdesktop.

> The question for me simply is: can I now assume that every new file created
> under KDE respects the umask
Files that are really _created_ have always respected the umask.
The problem was for files which are "created" by in fact being copied from a 
template file, like the Create New menu does. That one is fixed.
But if you know of any other means to create a file in KDE which didn't respect
the umask, please say so.

On the top of my head, I can't think of other places where this is done by copying
a file over. Even in KOffice where templates are used, the template is loaded into
the application, then you edit the document, and then you save to a new file
so it will respect the umask.

> - which in my eyes is the standard Unix (and for me personally desired) behaviour - 
Of course it is. The difficulty is to differenciate "copying an existing file" (which should
preserve permissions) from "copying a template file in order to create a new file" (which
should use the umask).

> or is this only a fix that works some of 
> the times, i.e. for konqueror and some other programs but not for openoffice
> or mozilla? 
Huh?? openoffice and mozilla are not part of KDE! Nothing I do in the KDE code
will change anything for openoffice and mozilla. If those have bugs, report to them.

Thanks you for the solution on permissions for copied templates!

That seemed to actually be the first thing reported in this bug entry. The next report suggested another problem that stands outside the template copy problem.

Apparently at some point of KDE's startup/init the default umask for all subsequently called programs is set to a fixed 022. When I start other DEs the umask works as expected. I have looked in startkde but have not found a umask line. The desired behaviour for KDE could just be to not read or specify any other umask by default. ~/.kde/share/env could be of help to revert it back to the desired setting, however though it might be good for personal changes within KDE it might be avoidable having to use it to just make KDE behave like the rest of the system.

I think this unexpected global umask change upon KDE startup is what let so many people to vote on this bug.

Where does the setDefaultPermissions() of the patch get the right system umask from?

Kind Regards,
Christian

On Wednesday 12 May 2004 13:26, C Gatzemeier wrote:
> Apparently at some point of KDE's startup/init the default umask for all subsequently called programs is set to a fixed 022. When I start other DEs the umask works as expected. I have looked in startkde but have not found a umask line. The desired behaviour for KDE could just be to not read or specify any other umask by default. ~/.kde/share/env could be of help to revert it back to the desired setting, however though it might be good for personal changes within KDE it might be avoidable having to use it to just make KDE behave like the rest of the system.
> 
> I think this unexpected global umask change upon KDE startup is what let so many people to vote on this bug.

I think you're not looking at the problem from the right angle.
KDE doesn't _reset_ the umask. The problem is more that your bashrc/profile/...
file that sets the umask isn't read ("sourced") at KDE startup.

This is the typical "kdm should read the profile" kind of request, which I'm not the
best person to answer (check with Ossi, kdm's author, I'm sure he knows why it's that way).

If I'm correct, then when you use "startx" the umask is correct (since in that
case it will have been set by the shell launching startx).

The ~/.kde/env/* solution that I implemented for 3.3 solves this, IMHO.

BTW another thing to try is to set the umask from the top of startkde.

Thanks for pointing out the kdm involvement, for all others interested here, I found the related bug #53345 .

Though explicitly putting the umask into startkde could be a workaround, I don't think it is a solution. Hopfully it is possible to straight things out in distribution policy. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=250645)

I think my problem has something to do with this bug, but I didn't solve it : http://article.gmane.org/gmane.comp.kde.linux/12382

Anyone can tell me what's wrong ?

> I think my problem has something to do with this bug, but I didn't solve it : http://article.gmane.org/gmane.comp.kde.linux/12382
> 
> Anyone can tell me what's wrong ?

You're using a version of KDE from before I fixed the bug - what do you expect?