linux-kernel - Re: [PATCH] ntsync: Set the permissions to be 0666

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1911589.tdWV9SEqCh@camazotz>
Date: Fri, 14 Feb 2025 12:13:03 -0600
From: Elizabeth Figura <zfigura@...eweavers.com>
To: Mike Lothian <mike@...eburn.co.uk>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: dri-devel@...ts.freedesktop.org, Arnd Bergmann <arnd@...db.de>,
 Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>,
 linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
 wine-devel@...ehq.org, André Almeida <andrealmeid@...lia.com>,
 Wolfram Sang <wsa@...nel.org>, Arkadiusz Hiler <ahiler@...eweavers.com>,
 Peter Zijlstra <peterz@...radead.org>, Andy Lutomirski <luto@...nel.org>,
 Randy Dunlap <rdunlap@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
 Boqun Feng <boqun.feng@...il.com>
Subject: Re: [PATCH] ntsync: Set the permissions to be 0666

On Friday, 14 February 2025 07:06:20 CST Greg Kroah-Hartman wrote:
> On Fri, Feb 14, 2025 at 12:28:00PM +0000, Mike Lothian wrote:
> > This allows ntsync to be usuable by non-root processes out of the box
> 
> Are you sure you need/want that?  If so, why?  How did existing testing
> not ever catch this?

Hi, sorry, this is of course my fault.

We do need /dev/ntsync to be openable from user space for it to be useful. I'm not sure what the most "correct" permissions are to have in this case (when we don't specifically need read or write), but I don't think I see a reason not to just set to 666 or 444.

I originally assumed that the right way to do this was not to set the mode on the kernel file but rather through udev; I believe I was using the code for /dev/loop-control or /dev/fuse as an example, which both do that. So I (and others who tested) had just manually set up udev rules for this, with the eventual intent of adding a default rule to systemd like the others. I only recently realized that doing something like this patch is possible and precedented.

I don't know what the best way to address this is, but this is certainly the simplest.