UIDについての私の理解は、Unixのようなオペレーティングシステムによって各ユーザーに割り当てられた一意の正の整数であるということです。各ユーザーは、UIDによってシステムに対して識別され、ユーザー名は一般に人間のインターフェースとしてのみ使用されます。
2人のユーザーがどのように同じUIDを持つことができますか?これは私のシステムとパッケージの競合ではありませんか?
root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#
同じUIDとGIDを持つ2人のユーザーを追加しました:test12
とtest13
/etc/passwd
の出力:
client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh
useradd -ou 1005 -g1000 username.
でユーザーを追加しました
私はこれの目的がわからないので、パーミッションやユーザーログなどに影響を与えることができます。それで、ユーザーがuid=0
で追加され、gid=0
がrootアカウントのような権限を持つようになりました。
ここでの答えは、Linuxはあなたからあなたを保護しないということです。
本当にsu root
にしたい場合は、/ etcファイルにアクセスして、すべてのユーザーに同じUIDを付与してください。これは単なるテキストファイルです。
しかし、あなたは本当にそうすべきではなく、意図しない結果をもたらすでしょう。
これには実際に正当な理由があります。たとえば、私たちはそれぞれ自分のコンピューターを持っているラボで働いていましたが、$HOME
はサーバーによってエクスポートされた共有ドライブにありました。だから、私の$HOME
は
/users/terdon
/users
フォルダーは実際にはローカルマシン上ではなく、NFS経由でエクスポートされているため、I/Oが重い分析では、ラボのネットワークに負担をかけないようにローカルハードドライブに保存されたデータを使用します。そのために、私と他のすべてのユーザーには2人のユーザーがいました。1人はシステム全体のユーザーであり、もう1人は問題のマシンのローカルでした。ローカルユーザーの自宅は
/home/localuser
ただし、terdon
としてログインした場合でもlocaluser
としてログインした場合でも、ファイルに完全にアクセスする必要があり、システム管理者がlocaluser
とterdon
同じUID。そうすれば、現在ログインしているユーザーに関係なく、ローカルファイルを自由に操作できます。
2人のユーザーは同じUIDを持つことができます。これは、テキストファイル内の単なる数字であるため、既に使用されている値など、任意の値に設定できるためです。あなたが見てきたように、そうすることは良い考えではありません。
実際には、同じIDの2人のユーザーがいるのはかなり一般的です。 FreeBSDでは、通常、UID 0を持つ2人のユーザーがいます:rootとtoor。ルートは組み込みの/ bin/shシェルを使用し、toorは別のシェル(通常はbash)を使用します。
UnixシステムとLinuxは通常、/etc/passwd
ファイルの重複を禁止しません。このファイルの目的は、ユーザーのファイルをリストアップするときに、ls
などのコマンドラインツールで表示できる物理名にUIDを関連付けることです。
$ ls -n | head -5
total 986000
drwxrwxr-x. 3 1000 1000 4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--. 1 1000 1000 760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--. 1 1000 1000 972 Oct 6 20:26 abcdefg
drwxrwxr-x. 2 1000 1000 4096 Feb 11 03:34 advanced_linux_programming
このファイルの他の目的は、ユーザーがログインしたときに取得するシェルを指定することです。
$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash
Unixタイプのシステムでの一般的な攻撃ベクトルは、次のような行をシステムの/etc/passwd
ファイルに追加することです。
$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash
$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash
/etc/passwd
ファイルの役割はではなくはユーザーアカウントのみを追跡するためのものです。ユーザー名とパスワードを追跡する役割は、/etc/shadow
ファイルの役割です。 /etc/passwd
や/etc/group
などのファイルは、システムがディスクからファイルをリストするときに、人間が読める名前を提供するためのものです。
ファイルは実際の名前ではなくUID/GIDを使用してディスクに書き込まれることに注意してください。
$ stat afile
File: ‘afile’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd02h/64770d Inode: 6560621 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ saml) Gid: ( 1000/ saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
Birth: -
Uid:
とGid:
に注意してください。数字は実際にディスクに書き込まれるものです!
Linuxでは、すべてのユーザーとグループは実際には単なる数字です。これは、投稿したid
コマンドの出力が示すものです。
/etc/passwd
ファイルは、ユーザーnamesをユーザーIDs(numbers)にマッピングします。この例では、2つのユーザー名を同じユーザーIDにマッピングしているだけです。 。
事実上、1人のユーザーtest12
、ID 1005を作成しました。このユーザーは、2番目のユーザー名test13
も持っています。ただし、システムはUID 1005を最初に見つかったユーザー名にマッピングします。これはtest12
になります
Linuxは、これを行うことを妨げるシステムがないため、これを「許可」します。 /etc/passwd
は単なるテキストファイルであり、ユーザー名はそのファイルのエントリで見つかったUIDにマップされ、UIDはそのファイルで見つかった最初のユーザー名にマップされます。
ただし、作成したのは、他のシステム管理者にとって混乱を招く状況です。 test13
のUIDを変更して回避してください
これが今日許可されている理由は、単にシステムがそれを妨げないからです。
これが変更されると、管理者がこの機能を使用していたシステムが破損します(Terdonの例を参照)。したがって、これは変更されたことはなく、今後も変わるとは思いません。
当初はpasswdファイルとgroupファイルのみがあり、それらは目的を果たしていました。 adduserコマンドはなく、addgroupコマンドはありませんでした。ファイルはviまたはedを使用したルート。
いくつかの癖がありました!
使用する次のユーザーIDを記憶するために、管理者は!
のユーザー名を持つ最後の行として特別なユーザーを持つことが一般的でした(!
は無効なユーザー名だったためです) )そして、そのエントリは次のユーザーIDを保存するために使用されました。原油、私は認めますが、うまくいきました!それで、なぜ今日はアジャイル開発に似た、より複雑な腸を破壊するのですか?.
既知の欠陥がありました。主なものは、ls
のようなユーティリティがuser-id => name
をマップできるように、誰でも読み取り可能でなければならないことです。つまり、誰でも暗号化されたすべてのパスワード、およびシステム内のすべてのユーザーとIDを見ることができます。
一部のUnixシステムでは、いくつかのシェルスクリプトadduser
addgroup
が導入され始めました。これらはUnix間で一貫性がないため、多くの場合無視されました。
shadow
パスワードファイルが発明されるまでには、暗号化されたパスワードを非表示にすることで、セキュリティが少し強化されました。ここでも、十分な複雑さが追加されましたが、それでもかなり粗雑でシンプルでした。ユーティリティuseradd
およびgroupadd
が導入され、shadow
およびshadow-
が更新され続けました。まず、これらは多くの場合、ベンダー独自のadduser/addgroupユーティリティを囲む単純なシェルスクリプトラッパーでした。繰り返しになりますが、これで十分です。
コンピューターのネットワークが成長し、人々が仕事を成し遂げるために一度にいくつかの作業を行っていたため、passwd/group
ファイルの管理は悪夢になり、特にNFSでは、Yellow Pagesが軽減するためにNISとして知られるようになりました負担。
もう少し柔軟なものが必要であり、PAMが発明されたことが、今では明らかになってきました。あなたが本当に洗練されていて、一元化された、安全な、ユニークIDの、すべてのベルとホイッスル認証システムを望んでいるなら、認証するために中央のサーバー、おそらくRadiusサーバー、LDAPサーバーまたはActive Directoryを呼び出します。
世界は成長しました。しかし、passwd/group/shadowファイルは、まだ小さなユーザー/開発者/ラボのために残っています。私たちはまだすべての機能を必要としませんでした。哲学は今までに少し変わっていたと思います、「もっと良くしようと思ったら、まったく使わない」、心配しないでください。
これが、単純なpasswdファイルが変更されるとは思わない理由です。これ以上の意味はありません。30ポンドのRaspberry Piと、2人から3人のユーザーの監視温度、Twitterフィードに最適です。わかりました。ユーザーIDを一意にしたい場合は、ユーザーIDに少し注意する必要があり、愛好家がuseraddをラップするのを防ぐものは何もありません。必要であれば、最初にデータベース(ファイル)から次の一意のIDを選択して一意のIDを設定するスクリプト。やはりオープンソースです。
/etc/passwd
ファイルは、シンボリックユーザー名を実際のユーザーIDにマップするだけです。 1つのuserIDにマップする2つのシンボリック名を意図的に作成する場合、許可されます。
それは実際にそれを行うことが良いアイデアであることを意味しません。一部の人々は、この機能を利用できる非常に特殊な使用例を見つけたかもしれませんが、一般的にはすべきではありません。
Linux(および他のUNIX)は、管理者が何をしているかを知っているという意見を受け入れます。バカなことをするように言ったら、それはあなた自身のせいです。崖の上を運転するように車に言ったのと同じように、メーカーに行って、なぜ車でこれをさせたのか尋ねることはできません。
オペレーティングシステムが一意であると期待する識別子がありますが、それらはハードウェアの追跡に使用されます。特定の niversally Unique IDentifier がシステムファイルを含むハードドライブに対応しているという知識は、ハードウェア構成が変更されても動作を継続するのに役立つ場合があります。 Microsoftはこれらのグローバル一意識別子を呼び出し、それらを使用してすべてのWindowsソフトウェアを追跡します。皮肉なことに、これらの頭字語は適切に選択されていません。
OSの観点から見ると、ほとんどのユーザーおよびグループ識別子の変更は、外部インターフェイスの変更に相当します。衝突にもかかわらず正常に機能する可能性があります。主にシステムのユーザーとグループに必要なのは、それらが存在することです。ユーザーが何を必要としているかを知ることはできません。このような状況では、UNIXの哲学は、OSが管理者に自分が何をしているのかを知っていると想定し、管理者がそれを迅速に行えるようにすることです。
@andybalholmの答えを裏付ける証拠を見つけました。
FromAPUE、§8.15:
どのプロセスでも、実際の有効なユーザーIDとグループIDを見つけることができます。ただし、プログラムを実行しているユーザーのログイン名を知りたい場合もあります。
getpwuid
(getuid
())を呼び出すことができますが、1人のユーザーが複数のログイン名を持ち、それぞれが同じユーザーIDを持つ場合はどうでしょうか? (エントリごとに異なるログインシェルを持つために、同じユーザーIDを持つパスワードファイルに複数のエントリがある場合があります。)システムは通常、ログインした名前を追跡します(セクション6.8) 、およびgetlogin
関数は、そのログイン名を取得する方法を提供します。....
ログイン名を指定すると、
getpwnam
を使用して、パスワードファイルでユーザーを検索し、たとえばログインシェルを特定できます。
ところで、ログイン中に別のシェルに切り替えることができるかどうかを知りたいです。