Marc Lehmann writes:
> No, it just means gparted has a security bug, because the permissions
> did work as the user intended before gparted changed them without the
> users knowledge, and they would have worked if gparted wasn't insecurely
> exposing the files.
Claiming that the side effect of
On Fri, Feb 14, 2020 at 02:52:59PM -0500, Phillip Susi
wrote:
> > You keep making this false claim, but that doesn't lend it more
> > credence. POSIX permissions work the way they work, and if you think some
> > combination of permissions are wrong, what are the rules to determine
> > right and
Marc Lehmann writes:
> Maybe it helps when you realise thta chown can also modify a file...
Only root can do that. In any case, I was ceeding the point that it is
essentially the same thing.
> You yourself mentioned some - in any case, does this lead somewhere?
I was just curious if there
On Fri, Feb 14, 2020 at 10:11:13AM -0500, Phillip Susi
wrote:
> > doesn't matter how exactly I change a file, as long as I can change it
> > when I shouldn't be, it is a security bug.
>
> True, you can delete the file and replace it, but then it is now owned
> by you instead of the original
Marc Lehmann writes:
> When you recreate a file with different contents you have modified it.
> Anything else is weird word twisting, and not useful in this context - it
> doesn't matter how exactly I change a file, as long as I can change it
> when I shouldn't be, it is a security bug.
True,
On Tue, Feb 11, 2020 at 09:18:30AM -0500, Phillip Susi
wrote:
> > The effective permissions for a path depend on more than just the
> > permissions of the file it refers to. For example, a root-only readable
> > file can still be changed by normal users if the directory is writable for
> > them.
Marc Lehmann writes:
> It happens also for filesystems with correct permissions - maybe this is
> the point you have problems with?
>
> The effective permissions for a path depend on more than just the
> permissions of the file it refers to. For example, a root-only readable
> file can still be
On Mon, Feb 03, 2020 at 01:07:55PM -0500, Phillip Susi
wrote:
> > 3. Now *another user* on the same machine can access that file system,
> >which I unwittingly mounted and exposed.
>
> I get it, I just don't understand why you would have a filesystem around
> whose internal permissions were
Nicolas Braud-Santoni writes:
> The scenario at play is the following:
>
> 1. I am a user with some level of administrative privileges, and run gparted.
> 2. I resize a partition (btrfs, in Marc's initial report),
>causing it to be mounted under /tmp, with a mountpoint that's chmod 0777.
>
Hi Phillip,
On Thu, Dec 13, 2018 at 09:02:24AM -0500, Phillip Susi wrote:
> On 12/12/2018 11:59 PM, Marc Lehmann wrote:
> > As you say, there are several ways, some where the user can choose to
> > make the files accessible and some where she can choose to not make them
> > available.
>
> I'm
On 12/12/2018 11:59 PM, Marc Lehmann wrote:
> As you say, there are several ways, some where the user can choose to
> make the files accessible and some where she can choose to not make them
> available.
I'm not sure what you mean by this.
> The point is that the user should be in control of
On Wed, Dec 12, 2018 at 08:46:01AM -0500, Phillip Susi
wrote:
> I'm not sure this can be considered a bug.
Ugh.
> There are several ways the user could have the filesystem mounted in a
> non temporary manner and if the permissions of the filesystem allow them
> access, then they can access it.
On 12/12/2018 3:50 AM, Marc Lehmann wrote:
> Package: gparted
> Version: 0.25.0-1+b1
> Severity: normal
>
> Dear Maintainer,
>
> for some operations, gparted mounts partitions under /tmp/gparted-XX
> without any protection
> against access. This makes these partitions potentially accessible
Package: gparted
Version: 0.25.0-1+b1
Severity: normal
Dear Maintainer,
for some operations, gparted mounts partitions under /tmp/gparted-XX
without any protection
against access. This makes these partitions potentially accessible to other
users on the system while
the operation runs.
14 matches
Mail list logo
