linux-kernel - Re: [RFC PATCH] fuse: Clear SGID bit when setting mode in setacl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 3 Mar 2021 16:36:24 +0100
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Vivek Goyal <vgoyal@...hat.com>
Cc:     Luis Henriques <lhenriques@...e.de>, linux-fsdevel@...r.kernel.org,
        virtio-fs-list <virtio-fs@...hat.com>,
        linux-kernel@...r.kernel.org,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>
Subject: Re: [RFC PATCH] fuse: Clear SGID bit when setting mode in setacl

On Tue, Mar 2, 2021 at 5:26 PM Vivek Goyal <vgoyal@...hat.com> wrote:

> > I still feel that it should probably be fixed in virtiofsd, given fuse client
> > is expecting file server to take care of any change of mode (file
> > permission bits).
>
> Havid said that, there is one disadvantage of relying on server to
> do this. Now idmapped mount patches have been merged. If virtiofs
> were to ever support idmapped mounts, this will become an issue.
> Server does not know about idmapped mounts, and it does not have
> information on how to shift inode gid to determine if SGID should
> be cleared or not.
>
> So if we were to keep possible future support of idmapped mounts in mind,
> then solving it in client makes more sense.  (/me is afraid that there
> might be other dependencies like this elsewhere).
>
> Miklos, WDYT.

Hmm sounds like two different modes of operation.

1) shared, non-idmapped: need to take care of races, so do the sgid
clearing in the server
2) non-shared, idmapped: can only do it in client

The same applies to all the other FUSE_*_KILL* stuff, so I guess the
decision about the mode just needs to be tied to a flag in some way.
Not sure if an existing one could be used.

Thanks,
Miklos