- 投稿日:
確認環境
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.local
とpiyo.local
を192.168.1.10
に向け、それぞれにhogeユーザーとpiyoユーザーの認証情報を持たせることで両立できる。
因みに\192.168.1.10\hoge
にhogeユーザー、\192.168.1.10\piyo
にもhogeユーザーでログインすることはできるが、基本的に権限周りで問題が起きると思う。無難なのは何かしらグループを作っておき、そのグループであれば自由に読み書きできるフォルダをsambaの共有フォルダに設定することだろう。
- 投稿日:
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**
参考
- コマンドの実行結果を読み取る(1)(
...
, qx/.../) - とほほのWWW入門 - モジュール - とほほのWWW入門
- [外部コマンドの実行 [open2, open3] – mahori blog](https://mahori.jp/perl-external-command-2/)
- 投稿日:
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}
にはstrict
、lax
が入る。確認内容としてはシーケンスの一番最後の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で更新系処理をしない限り基本は問題にならないと思われる。
参考
- 2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか | 徳丸浩の日記
- Cookies: HTTP State Management Mechanism (httpwg.org)
- httpwgによるドラフトの仕様(ブラウザがこれを守るかどうかはまた別の話)