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
restrict
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
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
> > thro
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
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.
>
>
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
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
> per
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
On Thu, Aug 13, 2020 at 9:32 AM Captain Hypertext
wrote:
> I'm running Debian 9 with svn 1.8.17, but I also tried with svn 1.9.5, which
> I guess is the latest version supported by our OS. Basically, I'm tasked with
> updating the permission structure of our application servers because we've
>
I have a really weird problem which may be a bug.
I'm running Debian 9 with svn 1.8.17, but I also tried with svn 1.9.5,
which I guess is the latest version supported by our OS. Basically, I'm
tasked with updating the permission structure of our application servers
because we've been using root f
On Wed, Oct 30, 2013 at 10:18:35AM +0100, Attila Nagy wrote:
> On 10/30/13 09:56, Stefan Sperling wrote:
> >I believe it's the stupid code replaced below, which I wrote in r880420.
> >Because of it we end up setting perms based on umask upon every commit,
> >and end up
On 10/30/13 09:56, Stefan Sperling wrote:
I believe it's the stupid code replaced below, which I wrote in r880420.
Because of it we end up setting perms based on umask upon every commit,
and end up expanding restrictive file permissions.
This patch should fix the problem.
Indeed, the
vn
> >>makes it impossible/very hard to make it work, because it screws up
> >>real file permissions on each commits.
> >Yes, that's a valid point. Subversion will possibly write the file
> >and/or change permissions on commit in two cases, I think:
>
Hi,
On 10/24/13 22:05, Branko Čibej wrote:
As Thorsten has pointed out, this is a different case. BTW, I have a
similar solution, like contrib/asvn, but the current operation of svn
makes it impossible/very hard to make it work, because it screws up
real file permissions on each commits.
Yes
On 24.10.2013 14:08, Attila Nagy wrote:
> On 10/22/13 09:56, Branko Čibej wrote:
>> On 22.10.2013 07:13, Branko ?ibej wrote:
>>> On 21.10.2013 18:16, Attila Nagy wrote:
>>>> On 10/15/2013 08:09 AM, Attila Nagy wrote:
>>>>> I store OS images in
On 22.10.2013 07:13, Branko Čibej wrote:
> On 21.10.2013 18:16, Attila Nagy wrote:
>> On 10/15/2013 08:09 AM, Attila Nagy wrote:
>>> I store OS images in svn, so I need to record file permissions and
>>> ownership. For this, I use properties.
>>> But svn change
No, because Subversion does not promise to restore original file
> permissions, and therefore you shouldn't rely on it to do so.
It's not about restoring, but not changing them during/after a commit.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:thors
Guten Tag Branko Čibej,
am Dienstag, 22. Oktober 2013 um 07:13 schrieben Sie:
> No, because Subversion does not promise to restore original file
> permissions, and therefore you shouldn't rely on it to do so.
It's not about restoring, but not changing them during/afte
On 21.10.2013 18:16, Attila Nagy wrote:
> On 10/15/2013 08:09 AM, Attila Nagy wrote:
>>
>> I store OS images in svn, so I need to record file permissions and
>> ownership. For this, I use properties.
>> But svn changes real file permissions:
> OK, long story short. Is
On 10/15/2013 08:09 AM, Attila Nagy wrote:
I store OS images in svn, so I need to record file permissions and
ownership. For this, I use properties.
But svn changes real file permissions:
OK, long story short. Isn't this a security issue?
$ ls -li zzz
4262518 -rw--- 1 bra bra
Hi,
I store OS images in svn, so I need to record file permissions and
ownership. For this, I use properties.
But svn changes real file permissions:
# ls -l fstab
-rw-r--r-- 1 root wheel 230 Oct 22 2011 fstab
# svn pg file:permissions fstab
mode=33188 user=(0) group=(0)
# chmod 600 fstab
> one special file should have 777
You can make it 755 by committing the svn:executable property on the
file, but I don't think there is anything similar for pure access control.
--
Stein
Hi, Ive got a problem with file permissions.
All files in the project have 644, but one special file should have 777,
because I need to change content of the file, using web interface...
I set 777 permissions for the file, but after svn update (if this
file has changed), again the 644
o, and you know that extra steps are usually skipped, if they could be
>> skipped.
>>
>> Nevertheless, I see no valid reason for the administrative ".svn"
>> directories to be world-wide accessible; correct me if I'm wrong. That's
>> why I propose th
y to checkout the tree
> properly and safely, but this is an extra step which developers have to
> do, and you know that extra steps are usually skipped, if they could be
> skipped.
>
> Nevertheless, I see no valid reason for the administrative ".svn"
> directories to b
e
> skipped.
>
> Nevertheless, I see no valid reason for the administrative ".svn"
> directories to be world-wide accessible; correct me if I'm wrong. That's
> why I propose that SVN creates these ".svn" directories with file
> permissions which disallow "
cessible; correct me if I'm wrong. That's
why I propose that SVN creates these ".svn" directories with file
permissions which disallow "others" to enter these directories. Here is
the proposed patch against the source code of Subversion 1.6.6:
--- ./subversion/libsvn_w
27 matches
Mail list logo
