横浜市で別人の住民票の写しが印刷された問題、タイムアウトによるファイルロック解除が原因 62
ストーリー by nagazou
トラブル 部門より
トラブル 部門より
横浜市のコンビニの証明書交付サービス「Fujitsu MICJET コンビニ交付」で3月27日、別人の住民票が発行されるトラブルが発生したそうだ。日経クロステックの報道によると、このサービスを提供しているベンダーの富士通Japanは3月30日、このトラブルに関する原因を発表した。それによると、システムへのアクセス集中により印刷処理の待ちが生じ、印刷イメージファイルのロックが解除され、同時期に交付を申請した別の利用者が当該ファイルを印刷できてしまったという（日経クロステック、その2）。
当該ファイルは申請者しか印刷できないようロックがかかる仕様だが、システムにはタイムアウトの上限が設定されていたため、アクセス集中で処理が遅れた際にタイムアウトとなってロックが解除されたという。同社は対策としてタイムアウトでロックが解除されないようプログラムを改修したとしている。
当該ファイルは申請者しか印刷できないようロックがかかる仕様だが、システムにはタイムアウトの上限が設定されていたため、アクセス集中で処理が遅れた際にタイムアウトとなってロックが解除されたという。同社は対策としてタイムアウトでロックが解除されないようプログラムを改修したとしている。
どれくらいの負荷なんだろう (スコア:1)
3月27日だから、それなりに人数は多いのだと思うけれど、
住民票の印刷ぐらいでそんなに負荷がかかるものなんだろうか。
コンビニ側の端末にデータを残さないために暗号化するにせよ、
住民票って、PDFにすれば数百キロバイトぐらいで済む
テキストデータだと思うんだけど。
Re:どれくらいの負荷なんだろう (スコア:1)
やっつけデスマくらいじゃないかな
# え？作らされる側の負荷じゃない？
Re:どれくらいの負荷なんだろう (スコア:1)
負荷テストを十分にしてないのか
結果ありきの無意味なテストか
それとも社員が働かないからなのか
Re: (スコア:0)
それじゃプリンタによって表示が変わってしまうだろ。
印刷イメージファイルってあるし、どんなプリンタで印刷しても同じものが出力されるようになってるのであろう。
数Mバイトにはなるかな。
といっても通信負荷ではなく、サーバ側のイメージの生成の処理負荷かもしれない。
Re: (スコア:0)
3000*2000ピクセルくらいだとすると無圧縮でも1MB超えるとは思えないんだけど
Re: (スコア:0)
>フルカラー 300～400dpi
>グレースケール 600dpi
>モノクロ二階調 1200dpi
https://blog.mc-copy.jp/scan/a4-print-resolution/ [mc-copy.jp]
Re: (スコア:0)
Re: (スコア:0)
じゃあ何dpiなの？ｗ
Re: (スコア:0)
住民票の紙なんですが役所からもらったものをコピーすると「複写」という文字が浮き上がるようになってますね。
あれって紙の地に印刷でもされてるんですかね。それとも印刷時に一緒に背景として出力してるんでしょうか。
そこを解決できれば読める解像度で多少ジャギっていても問題ないような気がしますけど……
Re: (スコア:0)
そういう紙に印刷してます。
印刷屋さんによって「複写」の文字が薄かったりする場合があってコピーのテストもやってましたね（過去形）
根本的解決になってない気がする (スコア:1)
これって、ロックしてなければ「他人のファイルを印刷してしまう」というファイル名管理の出来てなさが根本的原因だと思うし、そこは解決してないのが気になる。
「複数の印刷処理が同じファイル名を割り当てる場合がある」が、通常は「先に印刷開始した方がロックする」ので「後の方はロック解除されてから印刷処理する」から問題ないってことなんだと思いますが、
後発はがロック解除を待ってる間が処理が止まるので、ファイル名を衝突しないようにしたら負荷が軽くなりそう。
って、偉そうなこと書きましたが、年月日時分秒ミリ秒のファイル名が衝突したトラブルを起こしたことがあるのでAC。
Re: (スコア:0)
「年月日時分秒ミリ秒」プラス、マイナンバーをファイル名に含めれば大丈夫。
Re: (スコア:0)
> マイナンバーをファイル名に含めれば
それダメじゃね？
Re: (スコア:0)
多分そういう抱腹絶倒ギャグ
Re: (スコア:0)
これ、マイナンバーのハッシュ値（必要ならソルトを入れる）だったらOKなのだろうか
Re:根本的解決になってない気がする (スコア:2, 参考になる)
裏個人番号にあたるのでアウトでしょうね
行政手続きに使われる「xID」がマイナンバー法違反の指摘。これを受け自治体でアプリ利用停止へ | スラド セキュリティ [security.srad.jp]
Re: (スコア:0)
テンポラリファイルの生成は使ってる環境のフレームワークに任せるのが基本…
なんだけどうちでも社員番号だけをテンポラリファイル名にしてるシステムがあるんだよなあ。
もちろん666
Re: (スコア:0)
この手のサービスだとハードウェアの制限からそんなものは使えないそうです
Re: (スコア:0)
>年月日時分秒ミリ秒のファイル名が衝突したトラブルを起こしたことがある
あえて分までのファイル名にしてコメントに
「1分で処理が終わるようないいマシンを買ってもらえたら直してください」
ってスクリプトに残したことならある。
結局買ってもらえず、その後、時代はWindows全盛へ向かったため、そのスクリプトはお役御免。
Re: (スコア:0)
時刻合わせが常に正しい前提なので
複数のPCをまたぐ場合とか日時を過信しちゃダメなんだよな
Re: (スコア:0)
人手を介さない要求は不可能かつミリ秒まで一致するレベルでの操作不可能なのでこんな仕様に
Re: (スコア:0)
要求元の端末名が大文字・小文字違いの同じ配列の文字列でバッティングしたことあるなぁ・・・
要求元のホスト名称を大文字にして帳票に入れ込んで出力する仕様だったのでシステム側で対処のしようがなく、
バッティングした端末名変えてもらって事無きを得ましたが。
#WorkGroup運用の上、PC自体は別のセグメントに設置されてたのでそれまで特にエラーも出てなかったようなのですが・・・
そもそも (スコア:0)
セッションに紐付いた1:1の（毎回生成しているであろう）イメージファイルにロック掛ける意味ってなに
Re:そもそも (スコア:1)
バグ以前の問題で、ハイリスクな設計になっているね。
エラーが起きたら失敗だけで済まずに大事故になるという。
富士通って海外でも大事故を起こすバグとか出してたり、日本衰退を具現化している大企業って感じ。
Re: (スコア:0)
ロックが必要になること自体おかしいよねぇ……
別コメにもあるけど一定確率か一定条件でイメージファイル名が衝突するトンデモ実装だったとしか思えない
Re: (スコア:0)
ロックしている間のリソースを保証することで並行処理やリソース計算が容易になり仕様がシンプルになる
ただしバグるとこうなる
Re: (スコア:0)
コンビニからの要求はJ-LISの広域交付サーバーに来て、広域交付サーバが各自治体のコンビニ交付サーバー（横浜市は富士通製）に要求する仕組みなんだよね。
コンビニ交付サーバーはメーカーがまちまち。
だから、セッションの管理が厳密にできる仕様かどうか怪しいと思う。
Re: (スコア:0)
ロックが不要だし、ロックに頼ったとしてもロックが解除されてほしいケースが無い気がする。
- 印刷が完了してイメージファイルが削除される
- タイムアウトしてイメージファイルが削除される
他に考えられる分岐があるかな。
Re: (スコア:0)
ガベージコレクタとか。
異常終了した場合にはファイル削除処理が走らないんじゃないかな。
まあタイムアウト設定があるならファイル作成日時確認すればすむ話ではあるが。
Re: (スコア:0)
自治体のサーバから渡される印刷イメージファイルのパスが固定なんじゃね。
で、要件でコピーとリネームが禁止されていて
送信処理も隠蔽されててファイルパス渡して完了待つようなAPIなら、送信中は排他取るしかないかな。
ま〜た富士通か (スコア:0)
エネループ以外はホントダメだなここ。
Re: (スコア:0)
エネループは三洋電機→パナソニックで富士通はミリも関係ないが?
Re:ま〜た富士通か (スコア:2, 興味深い)
そのエネループの製造を請け負ってるのが富士通の子会社
パナソニックが三洋の電池部門を引き取ると
独占禁止法で手続きが面倒な事になるので
富士通に譲渡して対応した経緯がある
今もパナソニックが富士通から供給受けてる
そして富士通はエネループと同等性能の充電池を売ってるという
性能ほぼ同じで富士通製の方が安いので
事情知ってる人は富士通製の方を買ってる
Re:ま〜た富士通か (スコア:1)
富士通の子会社では有るけど
資本関係の整理で富士通の子会社になっただけで富士通が作った会社ではない。
富士電機から富士通の下に移動したのは通信機器と電池が近いからか？
元々とは東芝の電池工場の一部だった。
ちなみに東芝が電池から撤退するときに残りを引き取ったのもFDK。
Re: (スコア:0)
> 事情知ってる人は富士通製の方を買ってる
自分、今年になってFDKのこと知ったんですが、値上げされてエネループと値段があまり変わりません。
知るのが遅かったみたいです。
Re: (スコア:0)
FDK ぼそっ
Re: (スコア:0)
失敗を有耶無耶にして次の仕事を取ってくるのは上手ですね。
Re: (スコア:0)
今日はやけに富士通を叩くコメントが多いな。あちこちのストーリーに出没してる。
Re: (スコア:0)
不治痛に親を殺された奴は多いからな
Re: (スコア:0)
国籍差別と変わんないような叩き方だよな
Re: (スコア:0)
富士通のスマホ被害者が富士通を許すわけもなし。
Windows 95のクリティカルセクション (スコア:0)
プロセスが強制終了すると勝手に開放される、頭おかしいとAdvanced Windowsの著者がMSDN magazineでキレて代替のライブラリ(Optex)を誌面に掲載していたのを思い出す
Re: (スコア:0)
ミューテックスorセマフォではなくて？
Re: (スコア:0)
インプロセス用ですね。当然の動作だとしか思えん。
C#でクリティカルセクションの中でasync/awaitを書いたらVisualStudioもちゃんと指摘してくれるぐらいの話。
Re: (スコア:0)
確かに言われてみたらなんかおかしいなと思って記事を見返してみたら、プロセスじゃなくてスレッドだった。スレッドがクリティカルセクションを取得している間にTerminateThreadで殺されると、そのクリティカルセクションは解放されず他のスレッドはクリティカルセクションに入れなくなるべきだし、NTでは実際そのように実装されているが、Win95はそうではないという話。
Re: (スコア:0)
https://learn.microsoft.com/ja-jp/windows/win32/api/synchapi/nf-syncha... [microsoft.com]
クリティカル セクションの所有権がある間にスレッドが終了した場合、クリティカル セクションの状態は未定義です。
所有権持ったまま死なすほうが変て話なんだけどな。
まぁそんな古いもの今更どうでもいい話なんだが。
Re: (スコア:0)
> 所有権持ったまま死なすほうが変
まあそれはTerminateThread使うなという話に帰着するが。死んでもクリティカルセクション中の中途半端なデータ状態が自動的に復元されるわけではないのだから、自動的に所有権を解放して別のスレッドに処理開始を許したら、データ破壊がどんどん進行していくだけ。
> そんな古いもの今更どうでもいい
クリティカルセクションは今でも現役バリバリで使われているはずだけどね。所有権持ったまま死なす現在のWindows(NT系)はおかしいと主張しているのかな
言い訳ばかり (スコア:0)
要は、システム設計が素人みたいな設計だったことだろな
なんで検証しないんだろうか？
それもこれも想定できるケース
こんないい加減なシステムに市民の大事な血税使われているのかよｗ
で、改修にまた税金投入ｗ
もしかして、仕組まれたバグで市から金を搾り取ることが目的だったりして
Re: (スコア:0)
新卒1年目にやらせたんじゃないのってくらいだな。ガチャゲーくらいでしか許されないレベル
Re: (スコア:0)
と過去に自身がやらかしたことは忘れるわけですねｗｗｗ
都合の良い思考ですね