You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2021/11/24 10:09:08 UTC
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 root 4096 Mär 26 2013 ..
> 656754 4 -rw------- 1 root crontab 1597 Nov 24 10:38 root
> 656533 4 drwxr-xr-x 4 root root 4096 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.Schoening@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
Posted by Stefan Sperling <st...@elego.de>.
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
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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
Posted by Stefan Sperling <st...@elego.de>.
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
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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
Posted by Stefan Sperling <st...@elego.de>.
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
Re: Changed file permissions after committing user-crontabs
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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
Posted by Daniel Sahlberg <da...@gmail.com>.
Den ons 24 nov. 2021 kl 11:09 skrev Thorsten Schöning <tschoening@am-soft.de
>:
> 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