Dolphin ignores umask

[Emmett Culley]

I first discovered this issue when a user complained she could not access a file I created
on an NFS4 share.

I don't see this issue if I use fish:// to access any directory, local or remote.

We are on fully updated KDE fedora 34 and 35 systems, and this has been a problem for
quite awhile, through many Fedora updates, possibly as far back as fedora 18 (arbitrary
number).  Until now I've usually just run chmod -R g+w  on the share on the file
server or locally when it matters, then went about my business.  I have put it off too
long and so did a bit of investigation.

This happens every time on both Konqueror and Dolphin.  It never happens in Konsole. 
Meaning that if I open Konsole and cd to /fs1/work (the nfs share),  and create a file or
directory, the permissions are set to 664 and 2775 (SGID is set for all directories) as
expected, with a umask of 002 for all users.  Note that the umask on both servers and
clients are set to 002.

So only Dolphin and Konqueror ignore the umask=0002 setting, and only when not accessing a
file system via fish.  This happen on both remote NFS shares and locally.

Emmett

[Neal Gompa]

On Mon, Dec 27, 2021 at 10:17 AM Emmett Culley
<lst_manage(a)webengineer.com&gt; wrote:
>  I first discovered this issue when a user complained she could not access a file I
> created on an NFS4 share.
>
>  I don't see this issue if I use fish:// to access any directory, local or remote.
>
>  We are on fully updated KDE fedora 34 and 35 systems, and this has been a problem for
> quite awhile, through many Fedora updates, possibly as far back as fedora 18 (arbitrary
> number).  Until now I've usually just run chmod -R g+w  on the share on the file
> server or locally when it matters, then went about my business.  I have put it off too
> long and so did a bit of investigation.
>
>  This happens every time on both Konqueror and Dolphin.  It never happens in Konsole. 
> Meaning that if I open Konsole and cd to /fs1/work (the nfs share),  and create a file or
> directory, the permissions are set to 664 and 2775 (SGID is set for all directories) as
> expected, with a umask of 002 for all users.  Note that the umask on both servers and
> clients are set to 002.
>
>  So only Dolphin and Konqueror ignore the umask=0002 setting, and only when not accessing
> a file system via fish.  This happen on both remote NFS shares and locally.
>  
Please file a bug upstream at bugs.kde.org. Upstream KDE developers
look there for these things and will be able to do something about the
problem.




--
真実はいつも一つ！/ Always, there's only one truth!

[Emmett Culley]

On 12/27/21 8:01 AM, Neal Gompa wrote:
>  On Mon, Dec 27, 2021 at 10:17 AM Emmett Culley
>  <lst_manage(a)webengineer.com&gt; wrote:
> >
> > I first discovered this issue when a user complained she could not access a file I
> created on an NFS4 share.
> >
> > I don't see this issue if I use fish:// to access any directory, local or
> remote.
> >
> > We are on fully updated KDE fedora 34 and 35 systems, and this has been a problem for
> quite awhile, through many Fedora updates, possibly as far back as fedora 18 (arbitrary
> number).  Until now I've usually just run chmod -R g+w  on the share on the file
> server or locally when it matters, then went about my business.  I have put it off too
> long and so did a bit of investigation.
> >
> > This happens every time on both Konqueror and Dolphin.  It never happens in Konsole. 
> Meaning that if I open Konsole and cd to /fs1/work (the nfs share),  and create a file or
> directory, the permissions are set to 664 and 2775 (SGID is set for all directories) as
> expected, with a umask of 002 for all users.  Note that the umask on both servers and
> clients are set to 002.
> >
> > So only Dolphin and Konqueror ignore the umask=0002 setting, and only when not
> accessing a file system via fish.  This happen on both remote NFS shares and locally.
> >
>  
>  Please file a bug upstream at bugs.kde.org. Upstream KDE developers
>  look there for these things and will be able to do something about the
>  problem.
>  
>  
>  
>  
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  kde mailing list -- kde(a)lists.fedoraproject.org
>  To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>  
>  
https://bugs.kde.org/show_bug.cgi?id=392434

Emmett

[Martin]

Am Montag, 27. Dezember 2021, 17:01:00 CET schrieb Neal Gompa:
>  On Mon, Dec 27, 2021 at 10:17 AM Emmett Culley
>  <lst_manage(a)webengineer.com&gt; wrote:
>  
>  >
>  >
>  > I first discovered this issue when a user complained she could not access
>  > a file I created on an NFS4 share.
>
>  >
>  >
>  > I don't see this issue if I use fish:// to access any directory, local or
>  > remote.
>
>  >
>  >
>  > We are on fully updated KDE fedora 34 and 35 systems, and this has been a
>  > problem for quite awhile, through many Fedora updates, possibly as far
>  > back as fedora 18 (arbitrary number).  Until now I've usually just run
>  > chmod -R g+w  on the share on the file server or locally when it matters,
>  > then went about my business.  I have put it off too long and so did a bit
>  > of investigation.
>
>  >
>  >
>  > This happens every time on both Konqueror and Dolphin.  It never happens
>  > in Konsole.  Meaning that if I open Konsole and cd to /fs1/work (the nfs
>  > share),  and create a file or directory, the permissions are set to 664
>  > and 2775 (SGID is set for all directories) as expected, with a umask of
>  > 002 for all users.  Note that the umask on both servers and clients are
>  > set to 002.
>
>  >
>  >
>  > So only Dolphin and Konqueror ignore the umask=0002 setting, and only when
>  > not accessing a file system via fish.  This happen on both remote NFS
>  > shares and locally. 
Ah, I don't think that is a bug. I had the same issue, but not only for dolphin, but
all KDE 
apps (like kid3 etc.). So I stressed google up an down and finally found the reason for
it: 
KDE is started since some fedora versions via systemd --user part. And this systemd does 
not inherit parents umasks but sets it to 0022 by default - unless it is told to do
otherwise. 
This can be done in the systemd units via UMask setting or via pam_umask in the pam 
config files.

simple add "session optional pam_umask.so usergroups" to the
/etc/pam.d/system-auth 
file, reboot and login again - and dolphin should create files as requested (at least id
did 
for me during some short tests).

Regards
Martin
>  >
>  
>  
>  Please file a bug upstream at bugs.kde.org. Upstream KDE developers
>  look there for these things and will be able to do something about the
>  problem.
>  
>  
>  
>  
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  kde mailing list -- kde(a)lists.fedoraproject.org
>  To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
>  Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
>  Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure

[Martin]

Am Sonntag, 9. Januar 2022, 22:49:54 CET schrieb Martin:
>  Am Montag, 27. Dezember 2021, 17:01:00 CET schrieb Neal Gompa:
>  
>  Ah, I don't think that is a bug. I had the same issue, but not only for
>  dolphin, but all KDE apps (like kid3 etc.). So I stressed google up an down
>  and finally found the reason for it: KDE is started since some fedora
>  versions via systemd --user part. And this systemd does not inherit parents
>  umasks but sets it to 0022 by default - unless it is told to do otherwise.
>  This can be done in the systemd units via UMask setting or via pam_umask in
>  the pam config files.
>  
>  simple add "session optional pam_umask.so usergroups" to the
>  /etc/pam.d/system-auth file, reboot and login again - and dolphin should
>  create files as requested (at least id did for me during some short tests). 
I digged a little bit deeper and the entry in the system-auth file is a solution, but not
the 
fedora way of configuring - al least not completely.

My system is a very old one (about eight years) and upgraded over several fedora 
versions. The pam system was originally configured by a tool called authconfig (which 
changes system-auth and some other pam files). This tool is no longer available in fedora

35 and seems to be replaced by another tool called authselect.

If you don't plan to use authselect changing the system-auth file is fine. If you plan
to use 
it, this system-auth pam file will be overwritten. The umask part will work nevertheless,
as 
authselect uses the pam file postlogin for the pam_umask.so part (you have to configure 
UMASK in /etc/login.defs for using the default pam_umask module).

try "authselect test sssd" and check the output to see which files will be
changed/replaced 
with which content. I am currently investigation these changes and will test if this fits
my 
needs. If yes, i have a clean system and can update my pam system without any hassle.

Regards
Martin

>  
>  Regards
>  Martin
>  
>  > Please file a bug upstream at bugs.kde.org. Upstream KDE developers
>  > look there for these things and will be able to do something about the
>  > problem.
>  > 
>  > 
>  > 
>  > 
>  > --
>  > 真実はいつも一つ！/ Always, there's only one truth!
>  > _______________________________________________
>  > kde mailing list -- kde(a)lists.fedoraproject.org
>  > To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct:
>  > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
>  > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
>  > Archives:
>  > https://lists.fedoraproject.org/archives/list/[e-mail]
>  > Do not reply to spam on the list, report it:
>  > https://pagure.io/fedora-infrastructure

[Emmett Culley]

On 1/10/22 1:21 AM, Martin wrote:
>  Am Sonntag, 9. Januar 2022, 22:49:54 CET schrieb Martin:
>  
>   > Am Montag, 27. Dezember 2021, 17:01:00 CET schrieb Neal Gompa:
>  
>   >
>  
>   > Ah, I don't think that is a bug. I had the same issue, but not only for
>  
>   > dolphin, but all KDE apps (like kid3 etc.). So I stressed google up an down
>  
>   > and finally found the reason for it: KDE is started since some fedora
>  
>   > versions via systemd --user part. And this systemd does not inherit parents
>  
>   > umasks but sets it to 0022 by default - unless it is told to do otherwise.
>  
>   > This can be done in the systemd units via UMask setting or via pam_umask in
>  
>   > the pam config files.
>  
>   >
>  
>   > simple add "session optional pam_umask.so usergroups" to the
>  
>   > /etc/pam.d/system-auth file, reboot and login again - and dolphin should
>  
>   > create files as requested (at least id did for me during some short tests).
>  
>  
>  I digged a little bit deeper and the entry in the system-auth file is a solution, but not
> the fedora way of configuring - al least not completely.
>  
>  
>  My system is a very old one (about eight years) and upgraded over several fedora
> versions. The pam system was originally configured by a tool called authconfig (which
> changes system-auth and some other pam files). This tool is no longer available in fedora
> 35 and seems to be replaced by another tool called authselect.
>  
>  
>  If you don't plan to use authselect changing the system-auth file is fine. If you
> plan to use it, this system-auth pam file will be overwritten. The umask part will work
> nevertheless, as authselect uses the pam file postlogin for the pam_umask.so part (you
> have to configure UMASK in /etc/login.defs for using the default pam_umask module).
>  
>  
>  try "authselect test sssd" and check the output to see which files will be
> changed/replaced with which content. I am currently investigation these changes and will
> test if this fits my needs. If yes, i have a clean system and can update my pam system
> without any hassle.
>  
>  
>  Regards
>  
>  Martin
>  
>  
>   >
>  
>   > Regards
>  
>   > Martin
>  
>   >
>  
>   > > Please file a bug upstream at bugs.kde.org. Upstream KDE developers
>  
>   > > look there for these things and will be able to do something about the
>  
>   > > problem.
>  
>   > >
>  
>   > >
>  
>   > >
>  
>   > >
>  
>   > > --
>  
>   > > 真実はいつも一つ！/ Always, there's only one truth!
>  I first tried the pam method you suggested, as it seemed to be easier to do it once per
> workstation, but it didn't work.  For reasons you suggest above, I suppose :-)
>  
Then I used the systemd method you mentioned.  It was a little more painful because it has
to be done for each user on each workstation you want to change the UMASK for.  Lucky for
me I only have one other user on my system and only three workstations to configure.  I
was happy to find that it wasn't required to do anything on any of our servers, only
the workstations access thoe servers.

I did have to reboot each workstation after altering the systemd configuration before the
changed took effect.

Thanks for you suggestions.

I will add what I did to the bugs I reported.

Emmett

[Martin]

Am Montag, 10. Januar 2022, 10:21:04 CET schrieb Martin:
>  Am Sonntag, 9. Januar 2022, 22:49:54 CET schrieb Martin:
>  
>  I digged a little bit deeper and the entry in the system-auth file is a
>  solution, but not the fedora way of configuring - al least not completely.
>  
>  My system is a very old one (about eight years) and upgraded over several
>  fedora versions. The pam system was originally configured by a tool called
>  authconfig (which changes system-auth and some other pam files). This tool
>  is no longer available in fedora 35 and seems to be replaced by another
>  tool called authselect.
>  
>  If you don't plan to use authselect changing the system-auth file is fine.
>  If you plan to use it, this system-auth pam file will be overwritten. The
>  umask part will work nevertheless, as authselect uses the pam file
>  postlogin for the pam_umask.so part (you have to configure UMASK in
>  /etc/login.defs for using the default pam_umask module).
>  
>  try "authselect test sssd" and check the output to see which files will be
>  changed/replaced with which content. I am currently investigation these
>  changes and will test if this fits my needs. If yes, i have a clean system
>  and can update my pam system without any hassle. 
Another reply to myself :-)

I went the standard authselect path and umask was still set to 022 :-(. So I tried several

changes in the pam files. Adding pam_umaks to system-auth works, but all changes in 
postlogin did not. 
so I checked which pam.d files includes system-auth an does not include postlogin and 
bingo - systemd-user is the important pam.d file. adding "session include
postlogin" right 
after the line "session include system-auth" did the trick.

Now my systems are running as I want and use standard authselect sssd profiles. To my 
point of view this is a "bug" in the systemd-user pam.d file, this should
include the 
postlogin stuff as well.

Regards
Martin

>  
>  Regards
>  Martin
>  
>  > Regards
>  > Martin
>  > 
>  > > Please file a bug upstream at bugs.kde.org. Upstream KDE developers
>  > > look there for these things and will be able to do something about the
>  > > problem.
>  > > 
>  > > 
>  > > 
>  > > 
>  > > --
>  > > 真実はいつも一つ！/ Always, there's only one truth!
>  > > _______________________________________________
>  > > kde mailing list -- kde(a)lists.fedoraproject.org
>  > > To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
>  > > Fedora Code of Conduct:
>  > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
>  > > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
>  > > Archives:
>  > > https://lists.fedoraproject.org/archives/list/[e-mail]
>  > > g
>  > > Do not reply to spam on the list, report it:
>  > > https://pagure.io/fedora-infrastructure

[Emmett Culley]

On 1/10/22 10:50 AM, Martin wrote:
>  Am Montag, 10. Januar 2022, 10:21:04 CET schrieb Martin:
>  
>   > Am Sonntag, 9. Januar 2022, 22:49:54 CET schrieb Martin:
>  
>   >
>  
>   > I digged a little bit deeper and the entry in the system-auth file is a
>  
>   > solution, but not the fedora way of configuring - al least not completely.
>  
>   >
>  
>   > My system is a very old one (about eight years) and upgraded over several
>  
>   > fedora versions. The pam system was originally configured by a tool called
>  
>   > authconfig (which changes system-auth and some other pam files). This tool
>  
>   > is no longer available in fedora 35 and seems to be replaced by another
>  
>   > tool called authselect.
>  
>   >
>  
>   > If you don't plan to use authselect changing the system-auth file is fine.
>  
>   > If you plan to use it, this system-auth pam file will be overwritten. The
>  
>   > umask part will work nevertheless, as authselect uses the pam file
>  
>   > postlogin for the pam_umask.so part (you have to configure UMASK in
>  
>   > /etc/login.defs for using the default pam_umask module).
>  
>   >
>  
>   > try "authselect test sssd" and check the output to see which files will
> be
>  
>   > changed/replaced with which content. I am currently investigation these
>  
>   > changes and will test if this fits my needs. If yes, i have a clean system
>  
>   > and can update my pam system without any hassle.
>  
>  
>  Another reply to myself :-)
>  
>  
>  I went the standard authselect path and umask was still set to 022 :-(. So I tried
> several changes in the pam files. Adding pam_umaks to system-auth works, but all changes
> in postlogin did not.
>  
>  so I checked which pam.d files includes system-auth an does not include postlogin and
> bingo - systemd-user is the important pam.d file. adding "session include
> postlogin" right after the line "session include system-auth" did the
> trick.
>  
>  
>  Now my systems are running as I want and use standard authselect sssd profiles. To my
> point of view this is a "bug" in the systemd-user pam.d file, this should
> include the postlogin stuff as well.
>  
>  
>  Regards
>  
>  Martin
>  
>  
>   >
>  
>   > Regards
>  
>   > Martin
>  
>   >
>  
>   > > Regards
>  
>   > > Martin
>  
>   > >
>  
>   > > > Please file a bug upstream at bugs.kde.org. Upstream KDE developers
>  
>   > > > look there for these things and will be able to do something about the
>  
>   > > > problem.
>  
>   > > >
>  
>   > > >
>  
>   > > >
>  
>   > > >
>  
>   > > > --
>  
>   > > > 真実はいつも一つ！/ Always, there's only one truth!
>  
Will you file a bug report?  When investigating this issue I found that it wasn't only
Fedora with this problem.

I'd file the bug but I don't know enough about pam, especially as described above
:-)

Emmett

[Martin]

Am Montag, 10. Januar 2022, 20:00:03 CET schrieb Emmett Culley:
>  On 1/10/22 10:50 AM, Martin wrote:
>  
>  Will you file a bug report?  When investigating this issue I found that it
>  wasn't only Fedora with this problem. 
 
>  I'd file the bug but I don't know enough about pam,
> especially as described
>  above :-) 
OK, bug ist filed:  https://bugzilla.redhat.com/show_bug.cgi?id=2039047[1]

Let's see what will happen :-)

Martin

>  Emmett
>   

--------
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2039047