linux-kernel - Re: [PATCH] Add possibility to set /dev/tty number

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: <568BEDBA.1090006@gmail.com>
Date:	Tue, 5 Jan 2016 11:22:18 -0500
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	Theodore Ts'o <tytso@....edu>, G@...nk.org,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Greg KH <gregkh@...uxfoundation.org>,
	Pierre Paul MINGOT <mingot.pierre@...il.com>, jslaby@...e.cz,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add possibility to set /dev/tty number

On 2016-01-05 11:11, Theodore Ts'o wrote:
> On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
>>> We don't do regressions.
>> Requiring only a recompilation isn't a regression, especially when it works
>> fine without being recompiled, and I have yet to actually see anything that
>> changing the number of VT's would break other than ConsoleKit
>> (systemd-logind might also need a rebuild, but I'm not sure about that, and
>> don't have a system I could test it on).
>
> Sorry, breaking a compiled binary is a regression.
>
> People have outlined more clever ways of trying to accomplish your
> goal (saving memory) without breaking other people.  I suggest you
> give that a try instead of just trying to defend your existing patch.
>
First, it's not my patch.

Second, my usage of the term 'break' was probably not the best choice 
here, as ConsoleKit doesn't stop working.  All that happens is that it 
spits out some warnings about not finding VT's that it thinks should be 
there.  All that recompiling gets you is that it stops it from spitting 
out these warnings, which could just as easily be suppressed by other 
means.  And, while I can't personally test this, I'm pretty certain that 
the same applies to systemd-logind.  They have to gracefully cope with 
not being able to see all the VT's they think they should, because it's 
fully possible for something to hook into early boot and deallocate most 
of them before ConsoleKit or logind run.

Third, as Greg stated in his response to the patch, it should be updated 
so that the default matches current behavior, which would mean that 
nothing would break unless the person building the kernel chose to break it.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/