/mandos/release

To get this branch, use:
bzr branch http://bzr.recompile.se/loggerhead/mandos/release

« back to all changes in this revision

Viewing changes to plugins.d/usplash.xml

  • Committer: teddy at recompile
  • Date: 2020-12-03 20:30:45 UTC
  • mto: This revision was merged to the branch mainline in revision 404.
  • Revision ID: teddy@recompile.se-20201203203045-iqd6nq9y5nwalh1x
Minor fix of a test function

In dracut-module/password-agent, the test function
test_send_password_to_socket_EMSGSIZE() (which tests that the
send_password_to_socket() task function aborts properly when getting
EMSGSIZE when writing to the password socket), part of the test code
is supposed to find a message size which definitely does trigger
EMSGSIZE when send()ing to a socket.  Without a "break" in the proper
place, however, the size given is always exactly 1024 bytes too large.

This is very probably not a problem, since a too large message will
still be too large if it is increased by 1024 bytes, and send(2) in
practice checks the size before reading the buffer.  The biggest issue
would be if some version of send(2) would try to look at the last 1024
bytes of the message buffer before checking the message size; this
would then lead to a buffer over-read when running this test function.
(But even then there would be no security implications since the tests
are not run in the normal operation of the program.)

* dracut-module/password-agent.c
  (test_send_password_to_socket_EMSGSIZE): Break out early when ssret
  < 0 and errno == EMSGSIZE; don't allow loop to increase message_size
  again.

Show diffs side-by-side

added added

removed removed

Lines of Context:
2
2
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3
3
        "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4
4
<!ENTITY COMMANDNAME "usplash">
5
 
<!ENTITY TIMESTAMP "2009-01-04">
 
5
<!ENTITY TIMESTAMP "2019-02-10">
6
6
<!ENTITY % common SYSTEM "../common.ent">
7
7
%common;
8
8
]>
19
19
        <firstname>Björn</firstname>
20
20
        <surname>Påhlsson</surname>
21
21
        <address>
22
 
          <email>belorn@fukt.bsnet.se</email>
 
22
          <email>belorn@recompile.se</email>
23
23
        </address>
24
24
      </author>
25
25
      <author>
26
26
        <firstname>Teddy</firstname>
27
27
        <surname>Hogeborn</surname>
28
28
        <address>
29
 
          <email>teddy@fukt.bsnet.se</email>
 
29
          <email>teddy@recompile.se</email>
30
30
        </address>
31
31
      </author>
32
32
    </authorgroup>
33
33
    <copyright>
34
34
      <year>2008</year>
35
35
      <year>2009</year>
 
36
      <year>2010</year>
 
37
      <year>2011</year>
 
38
      <year>2012</year>
 
39
      <year>2013</year>
 
40
      <year>2014</year>
 
41
      <year>2015</year>
 
42
      <year>2016</year>
 
43
      <year>2017</year>
 
44
      <year>2018</year>
 
45
      <year>2019</year>
36
46
      <holder>Teddy Hogeborn</holder>
37
47
      <holder>Björn Påhlsson</holder>
38
48
    </copyright>
125
135
        <para>
126
136
          These variables will normally be inherited from
127
137
          <citerefentry><refentrytitle>plugin-runner</refentrytitle>
128
 
          <manvolnum>8mandos</manvolnum></citerefentry>, which will
129
 
          normally have inherited them from
130
 
          <filename>/scripts/local-top/cryptroot</filename> in the
131
 
          initial <acronym>RAM</acronym> disk environment, which will
132
 
          have set them from parsing kernel arguments and
133
 
          <filename>/conf/conf.d/cryptroot</filename> (also in the
134
 
          initial RAM disk environment), which in turn will have been
135
 
          created when the initial RAM disk image was created by
136
 
          <filename
137
 
          >/usr/share/initramfs-tools/hooks/cryptroot</filename>, by
138
 
          extracting the information of the root file system from
139
 
          <filename >/etc/crypttab</filename>.
 
138
          <manvolnum>8mandos</manvolnum></citerefentry>, which might
 
139
          have in turn inherited them from its calling process.
140
140
        </para>
141
141
        <para>
142
142
          This behavior is meant to exactly mirror the behavior of
177
177
        </listitem>
178
178
      </varlistentry>
179
179
      <varlistentry>
180
 
        <term><filename>/proc</filename></term>
 
180
        <term><filename class="directory">/proc</filename></term>
181
181
        <listitem>
182
182
          <para>
183
183
            To find the running <citerefentry><refentrytitle
216
216
      is ugly, but necessary as long as it does not support aborting a
217
217
      password request.
218
218
    </para>
 
219
    <xi:include href="../bugs.xml"/>
219
220
  </refsect1>
220
221
  
221
222
  <refsect1 id="example">
277
278
  <refsect1 id="see_also">
278
279
    <title>SEE ALSO</title>
279
280
    <para>
280
 
      <citerefentry><refentrytitle>crypttab</refentrytitle>
281
 
      <manvolnum>5</manvolnum></citerefentry>,
 
281
      <citerefentry><refentrytitle>intro</refentrytitle>
 
282
      <manvolnum>8mandos</manvolnum></citerefentry>,
282
283
      <citerefentry><refentrytitle>fifo</refentrytitle>
283
284
      <manvolnum>7</manvolnum></citerefentry>,
284
285
      <citerefentry><refentrytitle>plugin-runner</refentrytitle>