On 05/02/17 12:08, Kai Krakow wrote:
> Wrong. If you tend to not be in control of the permissions below a
> mountpoint, you prevent access to it by restricting permissions on a
> parent directory of the mountpoint. It's that easy and it always has
> been. That is standard practice. While your backu
Am Mon, 6 Feb 2017 07:30:31 -0500
schrieb "Austin S. Hemmelgarn" :
> > How about mounting the receiver below a directory only traversable
> > by root (chmod og-rwx)? Backups shouldn't be directly accessible by
> > ordinary users anyway.
> There are perfectly legitimate reasons to have backups di
On 2017-02-05 06:54, Kai Krakow wrote:
Am Wed, 1 Feb 2017 17:43:32 +
schrieb Graham Cobb :
On 01/02/17 12:28, Austin S. Hemmelgarn wrote:
On 2017-02-01 00:09, Duncan wrote:
Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as
excerpted:
[...]
I'm just a btrfs-using list regul
Am Thu, 2 Feb 2017 10:52:26 +
schrieb Graham Cobb :
> On 02/02/17 00:02, Duncan wrote:
> > If it's a workaround, then many of the Linux procedures we as
> > admins and users use every day are equally workarounds. Setting
> > 007 perms on a dir that doesn't have anything immediately security
>
Am Wed, 1 Feb 2017 17:43:32 +
schrieb Graham Cobb :
> On 01/02/17 12:28, Austin S. Hemmelgarn wrote:
> > On 2017-02-01 00:09, Duncan wrote:
> >> Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as
> >> excerpted:
> [...]
> >>
> >> I'm just a btrfs-using list regular not a dev,
On 2017-02-03 14:17, Graham Cobb wrote:
On 03/02/17 16:01, Austin S. Hemmelgarn wrote:
Ironically, I ended up having time sooner than I thought. The message
doesn't appear to be in any of the archives yet, but the message ID is:
<20170203134858.75210-1-ahferro...@gmail.com>
Ah. I didn't notic
On 03/02/17 16:01, Austin S. Hemmelgarn wrote:
> Ironically, I ended up having time sooner than I thought. The message
> doesn't appear to be in any of the archives yet, but the message ID is:
> <20170203134858.75210-1-ahferro...@gmail.com>
Ah. I didn't notice it until after I had sent my message
On 2017-02-03 10:44, Graham Cobb wrote:
On 03/02/17 12:44, Austin S. Hemmelgarn wrote:
I can look at making a patch for this, but it may be next week before I
have time (I'm not great at multi-tasking when it comes to software
development, and I'm in the middle of helping to fix a bug in Ansible
On 03/02/17 12:44, Austin S. Hemmelgarn wrote:
> I can look at making a patch for this, but it may be next week before I
> have time (I'm not great at multi-tasking when it comes to software
> development, and I'm in the middle of helping to fix a bug in Ansible
> right now).
That would be great,
On 2017-02-03 04:14, Duncan wrote:
Graham Cobb posted on Thu, 02 Feb 2017 10:52:26 + as excerpted:
On 02/02/17 00:02, Duncan wrote:
If it's a workaround, then many of the Linux procedures we as admins
and users use every day are equally workarounds. Setting 007 perms on
a dir that doesn't
Graham Cobb posted on Thu, 02 Feb 2017 10:52:26 + as excerpted:
> On 02/02/17 00:02, Duncan wrote:
>> If it's a workaround, then many of the Linux procedures we as admins
>> and users use every day are equally workarounds. Setting 007 perms on
>> a dir that doesn't have anything immediately s
On 2017-02-02 05:52, Graham Cobb wrote:
On 02/02/17 00:02, Duncan wrote:
If it's a workaround, then many of the Linux procedures we as admins and
users use every day are equally workarounds. Setting 007 perms on a dir
that doesn't have anything immediately security vulnerable in it, simply
to k
On 02/02/17 00:02, Duncan wrote:
> If it's a workaround, then many of the Linux procedures we as admins and
> users use every day are equally workarounds. Setting 007 perms on a dir
> that doesn't have anything immediately security vulnerable in it, simply
> to keep other users from even potent
Graham Cobb posted on Wed, 01 Feb 2017 22:51:34 + as excerpted:
>> [C]ouldn't the entire problem be eliminated by properly
>> setting the permissions on a directory/subvol upstream of the received
>> snapshot?
>
> I (honestly) don't know. But even if that does work, it is clearly only
> a wor
On 01/02/17 22:27, Duncan wrote:
> Graham Cobb posted on Wed, 01 Feb 2017 17:43:32 + as excerpted:
>
>> This first bug is more serious because it appears to allow a
>> non-privileged user to disrupt the correct operation of receive,
>> creating a form of denial-of-service of a send/receive bas
Graham Cobb posted on Wed, 01 Feb 2017 17:43:32 + as excerpted:
> This first bug is more serious because it appears to allow a
> non-privileged user to disrupt the correct operation of receive,
> creating a form of denial-of-service of a send/receive based backup
> process. If I decided that I
On 01/02/17 12:28, Austin S. Hemmelgarn wrote:
> On 2017-02-01 00:09, Duncan wrote:
>> Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as excerpted:
>>
>>> I have been testing btrfs send/receive. I like it.
>>>
>>> During those tests I discovered that it is possible to access and modify
On 2017-02-01 00:09, Duncan wrote:
Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as excerpted:
I have been testing btrfs send/receive. I like it.
During those tests I discovered that it is possible to access and modify
(add files, delete files ...) of the new receive snapshot duri
Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as excerpted:
> I have been testing btrfs send/receive. I like it.
>
> During those tests I discovered that it is possible to access and modify
> (add files, delete files ...) of the new receive snapshot during the
> transfer. After the t
I have been testing btrfs send/receive. I like it.
During those tests I discovered that it is possible to access and
modify (add files, delete files ...) of the new receive snapshot during
the transfer. After the transfer it becomes readonly but it could
already have been modified.
So you can end
20 matches
Mail list logo
