Re: Changed file permissions after committing user-crontabs
Guten Tag Daniel Sahlberg, am Mittwoch, 24. November 2021 um 22:22 schrieben Sie: > If you don't see it on newer Ubuntus - do you have another umask on these? Some have 0002, others 0022 and I found one with 0007. Though, all individual cron files on all systems I looked at have the same restricted permissions rw for users only. And I'm somewhat sure to have not changed umasks manually on all of those systems and/or changed permissions of cron files manually after committing. Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Fax: 05151- 9468-88 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
Re: Changed file permissions after committing user-crontabs
Den ons 24 nov. 2021 kl 11:09 skrev Thorsten Schöning : > I don't see this behaviour with newer SVN clients in > newer Ubuntus and don't have any similar old UB to test with. I tried it and it seems to me that I can reproduce it both on Ubuntu 12.04 (Subversion 1.6.17, even older than yours) and also on Fedora 32 (Subversion 1.14.1). If you don't see it on newer Ubuntus - do you have another umask on these? (I have seen Stefan Sperling's regarding the code that copies permissions - I just want to verify if there is a reason for the different results). Kind regards, Daniel Sahlberg
Re: Changed file permissions after committing user-crontabs
On Wed, Nov 24, 2021 at 04:20:12PM +0100, Thorsten Schöning wrote: > Guten Tag Stefan Sperling, > am Mittwoch, 24. November 2021 um 13:33 schrieben Sie: > > > This will be due to apr_file_mktemp() using default permissions > > on a freshly created temporary file. The committed file is run > > through translation (for keywords, newlines, and such) which > > involves a temporary file that gets reinstalled into the working copy. > > Is there any way to avoid that temporary file at all? I don't use > keywords and the newlines are as expected. Can e.g. the eol-property > or some other be set in a way to avoid all translations? I don't know. I have told you all I could figure out by skimming the code, and I don't have time to dive into more details. If a workaround is not enough for your needs, then someone else (not me) can study the libsvn_wc code in detail to figure out a proper solution. There is a function in libsvn_subr/io.c which copies unix perms from one file to another. This function is already being used in places. Perhaps a call to this function is missing from the commit code path such that permissions of files installed after committing them will be preserved. Cheers, Stefan
Re: Changed file permissions after committing user-crontabs
Guten Tag Stefan Sperling, am Mittwoch, 24. November 2021 um 13:33 schrieben Sie: > This will be due to apr_file_mktemp() using default permissions > on a freshly created temporary file. The committed file is run > through translation (for keywords, newlines, and such) which > involves a temporary file that gets reinstalled into the working copy. Is there any way to avoid that temporary file at all? I don't use keywords and the newlines are as expected. Can e.g. the eol-property or some other be set in a way to avoid all translations? Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Fax: 05151- 9468-88 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
Re: Changed file permissions after committing user-crontabs
On Wed, Nov 24, 2021 at 12:32:40PM +0100, Thorsten Schöning wrote: > Guten Tag Stefan Sperling, > am Mittwoch, 24. November 2021 um 11:17 schrieben Sie: > > > Subversion does not store file permission mode bits, except that the > > "executable" bit is preserved via the svn:mime-type property. > > I know and don't want SVN to store permissions. The file has correct > permissions before committing and doesn't anymore afterwards, that's > the problem I'm facing. Something is changing permissions of the file > during/after the commit and that need to be found and disabled. This will be due to apr_file_mktemp() using default permissions on a freshly created temporary file. The committed file is run through translation (for keywords, newlines, and such) which involves a temporary file that gets reinstalled into the working copy. As a workaround you could try running 'umask 077' before running svn commit on affected files, such that newly created files get the permission flags expected by cron. The default umask is 022.
Re: Changed file permissions after committing user-crontabs
Guten Tag Stefan Sperling, am Mittwoch, 24. November 2021 um 11:17 schrieben Sie: > Subversion does not store file permission mode bits, except that the > "executable" bit is preserved via the svn:mime-type property. I know and don't want SVN to store permissions. The file has correct permissions before committing and doesn't anymore afterwards, that's the problem I'm facing. Something is changing permissions of the file during/after the commit and that need to be found and disabled. Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Fax: 05151- 9468-88 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
Re: Changed file permissions after committing user-crontabs
On Wed, Nov 24, 2021 at 11:09:08AM +0100, Thorsten Schöning wrote: > Hi everyone, > > for various reasons I put /var/spool/cron/crontabs under version > control. I have one Ubuntu 12.04 legacy system running SVN 1.7.22 and > recognized that after committing changes to the file for ROOT, it's > permissions changed. > > > 655748 4 -rw--- 1 root crontab 1597 Nov 24 10:09 root > > vs. > > > 655748 4 -rw-r--r-- 1 root crontab 1597 Nov 24 10:09 root > > This made CRON ignoring the file with the following message: > > > Nov 23 12:56:01 [...] cron[1346]: (root) INSECURE MODE (mode 0600 expected) > > (crontabs/root) Subversion does not store file permission mode bits, except that the "executable" bit is preserved via the svn:mime-type property. You will want to use a wrapper tool such as 'asvn' for this use case: https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/asvn Cheers, Stefan
Changed file permissions after committing user-crontabs
Hi everyone, for various reasons I put /var/spool/cron/crontabs under version control. I have one Ubuntu 12.04 legacy system running SVN 1.7.22 and recognized that after committing changes to the file for ROOT, it's permissions changed. > 655748 4 -rw--- 1 root crontab 1597 Nov 24 10:09 root vs. > 655748 4 -rw-r--r-- 1 root crontab 1597 Nov 24 10:09 root This made CRON ignoring the file with the following message: > Nov 23 12:56:01 [...] cron[1346]: (root) INSECURE MODE (mode 0600 expected) > (crontabs/root) It was easy to fix this by re-running "crontab -e" and storing a new version of the file. But I needed a lot of time to find that problem in the logs. I don't see this behaviour with newer SVN clients in newer Ubuntus and don't have any similar old UB to test with. After looking into the settings of SVN, I couldn't find anything related to that as well. Though, I would have expected SVN to simply read the file during committing and nothing else. Especially as it doesn't contain any keywords or alike which SVN might substitue. Is that behaviour known to anybody? Might really the SVN client itself reset permissions for some reason? Is this somethign which can be disabled somewhere? Thanks! > root@[...]:/# ls -lisa /var/spool/cron/crontabs > insgesamt 16 > 655992 4 drwx-wx--T 3 root crontab 4096 Nov 24 10:38 . > 655990 4 drwxr-xr-x 5 root root4096 Mär 26 2013 .. > 656754 4 -rw--- 1 root crontab 1597 Nov 24 10:38 root > 656533 4 drwxr-xr-x 4 root root4096 Nov 24 10:38 .svn Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Fax: 05151- 9468-88 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska