お知らせ

現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。
投稿日:
OS::Linux::Ubuntuソフトウェア::その他

確認環境

Env Ver
Ubuntu 22.04.3 LTS

やり方

# sambaの導入
sudo apt install -y samba

# sambaユーザーの作成
export $NEW_USER=hoge
sudo useradd -s /usr/bin/zsh $NEW_USER
sudo passwd $NEW_USER
sudo mkdir /home/$NEW_USER
sudo smbpasswd -a $NEW_USER

# 必要最低限の設定を突っ込んでおく
sudo cp ~/.nanorc /home/$NEW_USER
sudo cp ~/.zshrc /home/$NEW_USER
sudo cp -R ~/.zsh /home/$NEW_USER
sudo chown -R $NEW_USER:$NEW_USER

# 元の設定退避
sudo cp smb.conf smb.conf.default
# 設定追加
cat <<EOF | sudo tee -a /etc/samba/smb.conf
[$NEW_USER]
path = /home/$NEW_USER/
browsable = yes
writable = yes
guest ok = no
read only = no
create mask = 0644
directory mask = 0755

vfs objects = recycle
recycle:repository = /home/$NEW_USER/.recycle
recycle:keeptree = yes
recycle:versions = yes
recycle:touch = no
recycle:maxsize = 0
recycle:exclude_dir = .recycle
EOF

トラブルシュート

同一IPのsambaに異なるユーザーでアクセスできない

例えば\192.168.1.10\hogeにhogeユーザー、\192.168.1.10\piyoにpiyoユーザーでアクセスしようとすると上手くいかない。これはWindowsの資格情報がホスト単位であるためと思われる。hostsにドメインを切るなどし、ホスト部を別個にすると上手くいくようになる。

この場合、hoge.localpiyo.local192.168.1.10に向け、それぞれにhogeユーザーとpiyoユーザーの認証情報を持たせることで両立できる。

因みに\192.168.1.10\hogeにhogeユーザー、\192.168.1.10\piyoにもhogeユーザーでログインすることはできるが、基本的に権限周りで問題が起きると思う。無難なのは何かしらグループを作っておき、そのグループであれば自由に読み書きできるフォルダをsambaの共有フォルダに設定することだろう。

投稿日:
Node.js

標準入力から読み込みたい時に

確認環境

Env Ver
Node.js 20.11.0

サンプルコード

/dev/stdinが存在するPOSIX系のシステム限定だと思われる。UbuntuとFreeBSDでは動いた。

const { readFileSync } = require('node:fs');

const stdIn = readFileSync('/dev/stdin', 'utf8');
console.log(stdIn);

おまけ

Markdownテキストを標準入力から取得して、生成したHTMLを標準出力に吐くやつ

投稿日:
言語::Perl

base64みたいなコマンドを使いたい時に

確認環境

Env Ver
Perl 5.34 .0

サンプルコード

バッククォートでコマンドを括り、後はシェルスクリプト度同じ理論で書くと行ける

# base64エンコードされた文字列
my $input = 'Kipib2xkKioKKml0YWxpYyoKfn5zdHJpa2V+fgotIGxpCiAgLSBzdAp8VEF8QkxFfAp8LS18LS0tfAp8YWF8YmJifAp8Y2N8ZGRkfAo=';
# 変数を標準出力に展開し、base64の標準入力として使い、base64コマンドの標準出力を戻り値の変数に格納している
my $output = `echo $input | base64 -d`;

print $output;

出力

**bold**
*italic*
~~strike~~
- li
  - st
|TA|BLE|
|--|---|
|aa|bbb|
|cc|ddd|

ダメだったコード

その1

# 標準ライブラリからopen2を取得
use IPC::Open2 qw/open2/;

my $pid = open2 *READ, *WRITE, 'base64 -d';
# base64エンコードされた文字列
print WRITE 'Kipib2xkKioKKml0YWxpYyoKfn5zdHJpa2V+fgotIGxpCiAgLSBzdAp8VEF8QkxFfAp8LS18LS0tfAp8YWF8YmJifAp8Y2N8ZGRkfAo=';
close WRITE;
my $output = <READ>;
close $READ;
waitpid $pid, 0;
print $output;

出力

何故か一行目しか出ない

**bold**

その2

# 標準ライブラリからopen2を取得
use IPC::Open2 qw/open2/;

my $pid = open2 my $reader, my $writer, 'base64 -d';
# base64エンコードされた文字列
print $writer 'Kipib2xkKioKKml0YWxpYyoKfn5zdHJpa2V+fgotIGxpCiAgLSBzdAp8VEF8QkxFfAp8LS18LS0tfAp8YWF8YmJifAp8Y2N8ZGRkfAo=';
close $writer;
my $output = <$reader>;
close $reader;
waitpid $pid, 0;
print $output;

出力

何故か一行目しか出ない

**bold**

参考

投稿日:
ソフトウェア::VSCode

Nanoで{Ctrl}+{Q}を終了に割り当ててたらVSCodeで終了できなくなったので、それを解消した話

確認環境

Env Ver
Visual Studio Code 1.85.2

方法

基本は"terminal.integrated.allowChords": falseで防げるが、それでも出てくるものについてはキーボードショートカットの設定から{Ctrl}+{Q}などで検索し、該当するコマンドを調べ"terminal.integrated.commandsToSkipShell": []に、頭に-を付加した、"-command"形式で記載すると出てこなくなる。

{
    "terminal.integrated.allowChords": false,
    "terminal.integrated.commandsToSkipShell": [
        "-workbench.action.quickOpenView",
    ],
}
投稿日:
技術::セキュリティ

前職で古いWebシステムのマイグレーションしてた時に思ったのだが、SameSite CookieがあればCSRF Tokenは最早いらないのではないか?というのに気が付いたので調べてみた話。

結論として言うとEdgeではPOSTリクエストでCookieが飛ぶ事はないので、CSRF Tokenを考慮する必要はなさそうに思える。

理由としてはCookieでSameSite=strictを指定している場合、クロスドメインでのCookie送信がブロックされるという話が事実であればCSRF Tokenは不要であるはずだからだ。

これによって悪意のあるサイトからAjaxやリダイレクト、フォームなどを使った攻撃をした場合にサーバーにCookieが送信されなくなる筈なので、理論上は問題なくなる。

以下では実際にCookieが送信されるかどうかの動きを見てみた。確認環境はMicrosoft Edge 121.0.2277.83。方式のリンクはシーケンス図になっている。

シーケンス図に書いてあるSameSite={var}{var}にはstrictlaxが入る。確認内容としてはシーケンスの一番最後のHTTPリクエストでCookieが送信されているかどうかを見ている。noneは面倒なので見ていない。

方式 SameSite=strict SameSite=lax
HTTP 302 REDIRECT 送信される 送信される
アンカーリンクのクリック 送信されない 送信される
アンカーリンクのクリック→HTTP 302 REDIRECT 送信されない 送信される
location.hrefでの移動 送信されない 送信される
location.hrefでの移動 →HTTP 302 REDIRECT 送信されない 送信される
FORMタグのsubmit(GET) 送信されない 送信される
FORMタグのsubmit(POST) 送信されない 送信されない

SameSite=strictだと外部サイトから開いたときにCookieが送信されないため、Google検索などから流入された時のログイン状態に不都合が出ると思われるので、その様なケースではSameSite=laxが無難だろう。

SameSite=laxの場合、GETリクエストではCookieが送信されるため、CSRF攻撃を受ける可能性があるが、GETで更新系処理をしない限り基本は問題にならないと思われる。

参考