Is this account of root privileges in UNIX correct?
Clash Royale CLAN TAG#URR8PPP
up vote
-1
down vote
favorite
Some university lecture notes claim that
In Unix systems, it is written into the operating system that some functionalities can only be accessed by the
root
user: modifying passwords, accessing to network ports used for communication protocols, interaction with hardware, etc.
Is this description correct? Where exactly is this implemented "in the OS"? How can non-root users change their own passwords if they cannot write /etc/passwd
?
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
security users root passwd
add a comment |Â
up vote
-1
down vote
favorite
Some university lecture notes claim that
In Unix systems, it is written into the operating system that some functionalities can only be accessed by the
root
user: modifying passwords, accessing to network ports used for communication protocols, interaction with hardware, etc.
Is this description correct? Where exactly is this implemented "in the OS"? How can non-root users change their own passwords if they cannot write /etc/passwd
?
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
security users root passwd
1
Is the latest incarnation of Apple's Mac operating system still a real (read: certified OR wholly-compliant to spec [unlike Linux]) UNIX? If so, that is an example of a real UNIX where root has limited power.passwd
is SUID. I feel that most of these restrictions are placed by the utilities and filesystem permissions rather than "the OS", but there are some assumptions "the OS" makes (e.g. the init system is run as UID 0)
â Fox
Oct 21 '17 at 14:17
Well, I guess OSX is just nix, isn't it?
â gen
Oct 21 '17 at 14:22
1
I've been prompted to check. macOS 10.12 and 10.13 on Intel-based computers are still certified by The Open Group. And some parts of the filesystem are non-writable by root under any circumstances on these systems (though you can boot to single-user mode and disable this). That was mostly just a response to your last paragraph
â Fox
Oct 21 '17 at 14:28
Putting a question mark at the end does not of itself turn a declarative statement into a question. If you want your last paragraph to be a question, then frame it as an actual question, not as something that has been incorrectly punctuated.
â JdeBP
Oct 21 '17 at 16:39
add a comment |Â
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
Some university lecture notes claim that
In Unix systems, it is written into the operating system that some functionalities can only be accessed by the
root
user: modifying passwords, accessing to network ports used for communication protocols, interaction with hardware, etc.
Is this description correct? Where exactly is this implemented "in the OS"? How can non-root users change their own passwords if they cannot write /etc/passwd
?
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
security users root passwd
Some university lecture notes claim that
In Unix systems, it is written into the operating system that some functionalities can only be accessed by the
root
user: modifying passwords, accessing to network ports used for communication protocols, interaction with hardware, etc.
Is this description correct? Where exactly is this implemented "in the OS"? How can non-root users change their own passwords if they cannot write /etc/passwd
?
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
security users root passwd
asked Oct 21 '17 at 14:03
gen
991
991
1
Is the latest incarnation of Apple's Mac operating system still a real (read: certified OR wholly-compliant to spec [unlike Linux]) UNIX? If so, that is an example of a real UNIX where root has limited power.passwd
is SUID. I feel that most of these restrictions are placed by the utilities and filesystem permissions rather than "the OS", but there are some assumptions "the OS" makes (e.g. the init system is run as UID 0)
â Fox
Oct 21 '17 at 14:17
Well, I guess OSX is just nix, isn't it?
â gen
Oct 21 '17 at 14:22
1
I've been prompted to check. macOS 10.12 and 10.13 on Intel-based computers are still certified by The Open Group. And some parts of the filesystem are non-writable by root under any circumstances on these systems (though you can boot to single-user mode and disable this). That was mostly just a response to your last paragraph
â Fox
Oct 21 '17 at 14:28
Putting a question mark at the end does not of itself turn a declarative statement into a question. If you want your last paragraph to be a question, then frame it as an actual question, not as something that has been incorrectly punctuated.
â JdeBP
Oct 21 '17 at 16:39
add a comment |Â
1
Is the latest incarnation of Apple's Mac operating system still a real (read: certified OR wholly-compliant to spec [unlike Linux]) UNIX? If so, that is an example of a real UNIX where root has limited power.passwd
is SUID. I feel that most of these restrictions are placed by the utilities and filesystem permissions rather than "the OS", but there are some assumptions "the OS" makes (e.g. the init system is run as UID 0)
â Fox
Oct 21 '17 at 14:17
Well, I guess OSX is just nix, isn't it?
â gen
Oct 21 '17 at 14:22
1
I've been prompted to check. macOS 10.12 and 10.13 on Intel-based computers are still certified by The Open Group. And some parts of the filesystem are non-writable by root under any circumstances on these systems (though you can boot to single-user mode and disable this). That was mostly just a response to your last paragraph
â Fox
Oct 21 '17 at 14:28
Putting a question mark at the end does not of itself turn a declarative statement into a question. If you want your last paragraph to be a question, then frame it as an actual question, not as something that has been incorrectly punctuated.
â JdeBP
Oct 21 '17 at 16:39
1
1
Is the latest incarnation of Apple's Mac operating system still a real (read: certified OR wholly-compliant to spec [unlike Linux]) UNIX? If so, that is an example of a real UNIX where root has limited power.
passwd
is SUID. I feel that most of these restrictions are placed by the utilities and filesystem permissions rather than "the OS", but there are some assumptions "the OS" makes (e.g. the init system is run as UID 0)â Fox
Oct 21 '17 at 14:17
Is the latest incarnation of Apple's Mac operating system still a real (read: certified OR wholly-compliant to spec [unlike Linux]) UNIX? If so, that is an example of a real UNIX where root has limited power.
passwd
is SUID. I feel that most of these restrictions are placed by the utilities and filesystem permissions rather than "the OS", but there are some assumptions "the OS" makes (e.g. the init system is run as UID 0)â Fox
Oct 21 '17 at 14:17
Well, I guess OSX is just nix, isn't it?
â gen
Oct 21 '17 at 14:22
Well, I guess OSX is just nix, isn't it?
â gen
Oct 21 '17 at 14:22
1
1
I've been prompted to check. macOS 10.12 and 10.13 on Intel-based computers are still certified by The Open Group. And some parts of the filesystem are non-writable by root under any circumstances on these systems (though you can boot to single-user mode and disable this). That was mostly just a response to your last paragraph
â Fox
Oct 21 '17 at 14:28
I've been prompted to check. macOS 10.12 and 10.13 on Intel-based computers are still certified by The Open Group. And some parts of the filesystem are non-writable by root under any circumstances on these systems (though you can boot to single-user mode and disable this). That was mostly just a response to your last paragraph
â Fox
Oct 21 '17 at 14:28
Putting a question mark at the end does not of itself turn a declarative statement into a question. If you want your last paragraph to be a question, then frame it as an actual question, not as something that has been incorrectly punctuated.
â JdeBP
Oct 21 '17 at 16:39
Putting a question mark at the end does not of itself turn a declarative statement into a question. If you want your last paragraph to be a question, then frame it as an actual question, not as something that has been incorrectly punctuated.
â JdeBP
Oct 21 '17 at 16:39
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
4
down vote
Is this description correct?
Yes and no, these statements are incomplete at best. More precisely:
- Modifying passwords: users can change their own password, but only
root
can change the passwords of other users. This is enforced by access permissions on/etc/shadow
. Thepasswd(1)
binary can bypass permissions on/etc/shadow
becausepasswd
is setuid toroot
, and thus it can gainroot
's privileges to write to/etc/shadow
. - Accessing to network ports used for communication protocols: only
root
can bind TCP and UDP ports below 1024, but everybody can bind any other port. This is enforced by the kernel. Also onlyroot
can use raw sockets (in particular this is whyping
needs to be setuid toroot
to run). But the details of accessing raw sockets are OS-dependent, and access can sometimes be granted by various non-standard ACL mechanisms. - Interaction with hardware: in principle only
root
processes can send raw commands to hardware. This is mainly enforced by permissions to the devices in/dev
. However most systems have mechanisms to allow users to bypass these permissions, f.i. to mount USB disks, write CDs, use audio hardware, etc.
Where exactly is this implemented "in the OS"?
There is a system of permissions implemented by the kernel. Most OSes supplement this system with various other mechanisms, such as OpenBSD's pledge
, or Linux's SELinux
.
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
Yes.
Here's some more good info on this: man.cat-v.org/unix-1st/5/passwd anonscm.debian.org/git/pkg-shadow/shadow.git/tree/src/passwd.c
â jdwolf
Oct 21 '17 at 16:40
@jdwolfpasswd(5)
is the file/etc/passwd
. I'm referring to the binary,passwd(1)
. As for the Debian binary, I'm not sure what's your point. It is meant to run setuid root, which allows users to change their own password.
â Satà  Katsura
Oct 21 '17 at 17:23
add a comment |Â
up vote
2
down vote
Lets go back to the original statement because I think its incorrect to compare to Linux here since Linux is not Unix.
The manual for the passwd command on Unix specifically states only root can use the utility.
http://man.cat-v.org/unix-1st/5/passwd
Similarly opening ports only privileged processes are allowed to change to certain ports. The sys/socket.h is defined under Unix.
http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html
and as described here:
http://man7.org/linux/man-pages/man7/ip.7.html
Permissions for this amounted to requiring root.
Interaction with hardware is slightly more broad even vague. But is likely referring to the fact that /dev/ interfaces such as mknod required root.
So the statement is essentially accurate.
It's also interesting to compare to Linux which for example uses a privilege system. Udev allows various levels of access to hardware. Passwd allows the same user to change their own passwd. And Linux uses PAM instead of just the getuid syscall. So none of these statements are true if we try to apply it to Linux.
â jdwolf
Oct 21 '17 at 17:12
The manual for the passwd command on Unix specifically states only root can use the utility. - You're readingpasswd(5)
, the manual for the file/etc/passwd
. Apparently UNIX didn't have apasswd(1)
back then, but it did in V6, and the man page explicitly states the user can change his own password.
â Satà  Katsura
Oct 21 '17 at 17:22
Thats a good point. You should edit it into the answer.
â jdwolf
Oct 21 '17 at 17:25
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
Is this description correct?
Yes and no, these statements are incomplete at best. More precisely:
- Modifying passwords: users can change their own password, but only
root
can change the passwords of other users. This is enforced by access permissions on/etc/shadow
. Thepasswd(1)
binary can bypass permissions on/etc/shadow
becausepasswd
is setuid toroot
, and thus it can gainroot
's privileges to write to/etc/shadow
. - Accessing to network ports used for communication protocols: only
root
can bind TCP and UDP ports below 1024, but everybody can bind any other port. This is enforced by the kernel. Also onlyroot
can use raw sockets (in particular this is whyping
needs to be setuid toroot
to run). But the details of accessing raw sockets are OS-dependent, and access can sometimes be granted by various non-standard ACL mechanisms. - Interaction with hardware: in principle only
root
processes can send raw commands to hardware. This is mainly enforced by permissions to the devices in/dev
. However most systems have mechanisms to allow users to bypass these permissions, f.i. to mount USB disks, write CDs, use audio hardware, etc.
Where exactly is this implemented "in the OS"?
There is a system of permissions implemented by the kernel. Most OSes supplement this system with various other mechanisms, such as OpenBSD's pledge
, or Linux's SELinux
.
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
Yes.
Here's some more good info on this: man.cat-v.org/unix-1st/5/passwd anonscm.debian.org/git/pkg-shadow/shadow.git/tree/src/passwd.c
â jdwolf
Oct 21 '17 at 16:40
@jdwolfpasswd(5)
is the file/etc/passwd
. I'm referring to the binary,passwd(1)
. As for the Debian binary, I'm not sure what's your point. It is meant to run setuid root, which allows users to change their own password.
â Satà  Katsura
Oct 21 '17 at 17:23
add a comment |Â
up vote
4
down vote
Is this description correct?
Yes and no, these statements are incomplete at best. More precisely:
- Modifying passwords: users can change their own password, but only
root
can change the passwords of other users. This is enforced by access permissions on/etc/shadow
. Thepasswd(1)
binary can bypass permissions on/etc/shadow
becausepasswd
is setuid toroot
, and thus it can gainroot
's privileges to write to/etc/shadow
. - Accessing to network ports used for communication protocols: only
root
can bind TCP and UDP ports below 1024, but everybody can bind any other port. This is enforced by the kernel. Also onlyroot
can use raw sockets (in particular this is whyping
needs to be setuid toroot
to run). But the details of accessing raw sockets are OS-dependent, and access can sometimes be granted by various non-standard ACL mechanisms. - Interaction with hardware: in principle only
root
processes can send raw commands to hardware. This is mainly enforced by permissions to the devices in/dev
. However most systems have mechanisms to allow users to bypass these permissions, f.i. to mount USB disks, write CDs, use audio hardware, etc.
Where exactly is this implemented "in the OS"?
There is a system of permissions implemented by the kernel. Most OSes supplement this system with various other mechanisms, such as OpenBSD's pledge
, or Linux's SELinux
.
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
Yes.
Here's some more good info on this: man.cat-v.org/unix-1st/5/passwd anonscm.debian.org/git/pkg-shadow/shadow.git/tree/src/passwd.c
â jdwolf
Oct 21 '17 at 16:40
@jdwolfpasswd(5)
is the file/etc/passwd
. I'm referring to the binary,passwd(1)
. As for the Debian binary, I'm not sure what's your point. It is meant to run setuid root, which allows users to change their own password.
â Satà  Katsura
Oct 21 '17 at 17:23
add a comment |Â
up vote
4
down vote
up vote
4
down vote
Is this description correct?
Yes and no, these statements are incomplete at best. More precisely:
- Modifying passwords: users can change their own password, but only
root
can change the passwords of other users. This is enforced by access permissions on/etc/shadow
. Thepasswd(1)
binary can bypass permissions on/etc/shadow
becausepasswd
is setuid toroot
, and thus it can gainroot
's privileges to write to/etc/shadow
. - Accessing to network ports used for communication protocols: only
root
can bind TCP and UDP ports below 1024, but everybody can bind any other port. This is enforced by the kernel. Also onlyroot
can use raw sockets (in particular this is whyping
needs to be setuid toroot
to run). But the details of accessing raw sockets are OS-dependent, and access can sometimes be granted by various non-standard ACL mechanisms. - Interaction with hardware: in principle only
root
processes can send raw commands to hardware. This is mainly enforced by permissions to the devices in/dev
. However most systems have mechanisms to allow users to bypass these permissions, f.i. to mount USB disks, write CDs, use audio hardware, etc.
Where exactly is this implemented "in the OS"?
There is a system of permissions implemented by the kernel. Most OSes supplement this system with various other mechanisms, such as OpenBSD's pledge
, or Linux's SELinux
.
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
Yes.
Is this description correct?
Yes and no, these statements are incomplete at best. More precisely:
- Modifying passwords: users can change their own password, but only
root
can change the passwords of other users. This is enforced by access permissions on/etc/shadow
. Thepasswd(1)
binary can bypass permissions on/etc/shadow
becausepasswd
is setuid toroot
, and thus it can gainroot
's privileges to write to/etc/shadow
. - Accessing to network ports used for communication protocols: only
root
can bind TCP and UDP ports below 1024, but everybody can bind any other port. This is enforced by the kernel. Also onlyroot
can use raw sockets (in particular this is whyping
needs to be setuid toroot
to run). But the details of accessing raw sockets are OS-dependent, and access can sometimes be granted by various non-standard ACL mechanisms. - Interaction with hardware: in principle only
root
processes can send raw commands to hardware. This is mainly enforced by permissions to the devices in/dev
. However most systems have mechanisms to allow users to bypass these permissions, f.i. to mount USB disks, write CDs, use audio hardware, etc.
Where exactly is this implemented "in the OS"?
There is a system of permissions implemented by the kernel. Most OSes supplement this system with various other mechanisms, such as OpenBSD's pledge
, or Linux's SELinux
.
As far as I know, there are UNIX-based systems like SELinux, where the root user doesn't have unlimited powers?
Yes.
edited Oct 21 '17 at 17:33
answered Oct 21 '17 at 14:39
Satà  Katsura
10.7k11533
10.7k11533
Here's some more good info on this: man.cat-v.org/unix-1st/5/passwd anonscm.debian.org/git/pkg-shadow/shadow.git/tree/src/passwd.c
â jdwolf
Oct 21 '17 at 16:40
@jdwolfpasswd(5)
is the file/etc/passwd
. I'm referring to the binary,passwd(1)
. As for the Debian binary, I'm not sure what's your point. It is meant to run setuid root, which allows users to change their own password.
â Satà  Katsura
Oct 21 '17 at 17:23
add a comment |Â
Here's some more good info on this: man.cat-v.org/unix-1st/5/passwd anonscm.debian.org/git/pkg-shadow/shadow.git/tree/src/passwd.c
â jdwolf
Oct 21 '17 at 16:40
@jdwolfpasswd(5)
is the file/etc/passwd
. I'm referring to the binary,passwd(1)
. As for the Debian binary, I'm not sure what's your point. It is meant to run setuid root, which allows users to change their own password.
â Satà  Katsura
Oct 21 '17 at 17:23
Here's some more good info on this: man.cat-v.org/unix-1st/5/passwd anonscm.debian.org/git/pkg-shadow/shadow.git/tree/src/passwd.c
â jdwolf
Oct 21 '17 at 16:40
Here's some more good info on this: man.cat-v.org/unix-1st/5/passwd anonscm.debian.org/git/pkg-shadow/shadow.git/tree/src/passwd.c
â jdwolf
Oct 21 '17 at 16:40
@jdwolf
passwd(5)
is the file /etc/passwd
. I'm referring to the binary, passwd(1)
. As for the Debian binary, I'm not sure what's your point. It is meant to run setuid root, which allows users to change their own password.â Satà  Katsura
Oct 21 '17 at 17:23
@jdwolf
passwd(5)
is the file /etc/passwd
. I'm referring to the binary, passwd(1)
. As for the Debian binary, I'm not sure what's your point. It is meant to run setuid root, which allows users to change their own password.â Satà  Katsura
Oct 21 '17 at 17:23
add a comment |Â
up vote
2
down vote
Lets go back to the original statement because I think its incorrect to compare to Linux here since Linux is not Unix.
The manual for the passwd command on Unix specifically states only root can use the utility.
http://man.cat-v.org/unix-1st/5/passwd
Similarly opening ports only privileged processes are allowed to change to certain ports. The sys/socket.h is defined under Unix.
http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html
and as described here:
http://man7.org/linux/man-pages/man7/ip.7.html
Permissions for this amounted to requiring root.
Interaction with hardware is slightly more broad even vague. But is likely referring to the fact that /dev/ interfaces such as mknod required root.
So the statement is essentially accurate.
It's also interesting to compare to Linux which for example uses a privilege system. Udev allows various levels of access to hardware. Passwd allows the same user to change their own passwd. And Linux uses PAM instead of just the getuid syscall. So none of these statements are true if we try to apply it to Linux.
â jdwolf
Oct 21 '17 at 17:12
The manual for the passwd command on Unix specifically states only root can use the utility. - You're readingpasswd(5)
, the manual for the file/etc/passwd
. Apparently UNIX didn't have apasswd(1)
back then, but it did in V6, and the man page explicitly states the user can change his own password.
â Satà  Katsura
Oct 21 '17 at 17:22
Thats a good point. You should edit it into the answer.
â jdwolf
Oct 21 '17 at 17:25
add a comment |Â
up vote
2
down vote
Lets go back to the original statement because I think its incorrect to compare to Linux here since Linux is not Unix.
The manual for the passwd command on Unix specifically states only root can use the utility.
http://man.cat-v.org/unix-1st/5/passwd
Similarly opening ports only privileged processes are allowed to change to certain ports. The sys/socket.h is defined under Unix.
http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html
and as described here:
http://man7.org/linux/man-pages/man7/ip.7.html
Permissions for this amounted to requiring root.
Interaction with hardware is slightly more broad even vague. But is likely referring to the fact that /dev/ interfaces such as mknod required root.
So the statement is essentially accurate.
It's also interesting to compare to Linux which for example uses a privilege system. Udev allows various levels of access to hardware. Passwd allows the same user to change their own passwd. And Linux uses PAM instead of just the getuid syscall. So none of these statements are true if we try to apply it to Linux.
â jdwolf
Oct 21 '17 at 17:12
The manual for the passwd command on Unix specifically states only root can use the utility. - You're readingpasswd(5)
, the manual for the file/etc/passwd
. Apparently UNIX didn't have apasswd(1)
back then, but it did in V6, and the man page explicitly states the user can change his own password.
â Satà  Katsura
Oct 21 '17 at 17:22
Thats a good point. You should edit it into the answer.
â jdwolf
Oct 21 '17 at 17:25
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Lets go back to the original statement because I think its incorrect to compare to Linux here since Linux is not Unix.
The manual for the passwd command on Unix specifically states only root can use the utility.
http://man.cat-v.org/unix-1st/5/passwd
Similarly opening ports only privileged processes are allowed to change to certain ports. The sys/socket.h is defined under Unix.
http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html
and as described here:
http://man7.org/linux/man-pages/man7/ip.7.html
Permissions for this amounted to requiring root.
Interaction with hardware is slightly more broad even vague. But is likely referring to the fact that /dev/ interfaces such as mknod required root.
So the statement is essentially accurate.
Lets go back to the original statement because I think its incorrect to compare to Linux here since Linux is not Unix.
The manual for the passwd command on Unix specifically states only root can use the utility.
http://man.cat-v.org/unix-1st/5/passwd
Similarly opening ports only privileged processes are allowed to change to certain ports. The sys/socket.h is defined under Unix.
http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html
and as described here:
http://man7.org/linux/man-pages/man7/ip.7.html
Permissions for this amounted to requiring root.
Interaction with hardware is slightly more broad even vague. But is likely referring to the fact that /dev/ interfaces such as mknod required root.
So the statement is essentially accurate.
answered Oct 21 '17 at 17:08
jdwolf
2,392116
2,392116
It's also interesting to compare to Linux which for example uses a privilege system. Udev allows various levels of access to hardware. Passwd allows the same user to change their own passwd. And Linux uses PAM instead of just the getuid syscall. So none of these statements are true if we try to apply it to Linux.
â jdwolf
Oct 21 '17 at 17:12
The manual for the passwd command on Unix specifically states only root can use the utility. - You're readingpasswd(5)
, the manual for the file/etc/passwd
. Apparently UNIX didn't have apasswd(1)
back then, but it did in V6, and the man page explicitly states the user can change his own password.
â Satà  Katsura
Oct 21 '17 at 17:22
Thats a good point. You should edit it into the answer.
â jdwolf
Oct 21 '17 at 17:25
add a comment |Â
It's also interesting to compare to Linux which for example uses a privilege system. Udev allows various levels of access to hardware. Passwd allows the same user to change their own passwd. And Linux uses PAM instead of just the getuid syscall. So none of these statements are true if we try to apply it to Linux.
â jdwolf
Oct 21 '17 at 17:12
The manual for the passwd command on Unix specifically states only root can use the utility. - You're readingpasswd(5)
, the manual for the file/etc/passwd
. Apparently UNIX didn't have apasswd(1)
back then, but it did in V6, and the man page explicitly states the user can change his own password.
â Satà  Katsura
Oct 21 '17 at 17:22
Thats a good point. You should edit it into the answer.
â jdwolf
Oct 21 '17 at 17:25
It's also interesting to compare to Linux which for example uses a privilege system. Udev allows various levels of access to hardware. Passwd allows the same user to change their own passwd. And Linux uses PAM instead of just the getuid syscall. So none of these statements are true if we try to apply it to Linux.
â jdwolf
Oct 21 '17 at 17:12
It's also interesting to compare to Linux which for example uses a privilege system. Udev allows various levels of access to hardware. Passwd allows the same user to change their own passwd. And Linux uses PAM instead of just the getuid syscall. So none of these statements are true if we try to apply it to Linux.
â jdwolf
Oct 21 '17 at 17:12
The manual for the passwd command on Unix specifically states only root can use the utility. - You're reading
passwd(5)
, the manual for the file /etc/passwd
. Apparently UNIX didn't have a passwd(1)
back then, but it did in V6, and the man page explicitly states the user can change his own password.â Satà  Katsura
Oct 21 '17 at 17:22
The manual for the passwd command on Unix specifically states only root can use the utility. - You're reading
passwd(5)
, the manual for the file /etc/passwd
. Apparently UNIX didn't have a passwd(1)
back then, but it did in V6, and the man page explicitly states the user can change his own password.â Satà  Katsura
Oct 21 '17 at 17:22
Thats a good point. You should edit it into the answer.
â jdwolf
Oct 21 '17 at 17:25
Thats a good point. You should edit it into the answer.
â jdwolf
Oct 21 '17 at 17:25
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f399550%2fis-this-account-of-root-privileges-in-unix-correct%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Is the latest incarnation of Apple's Mac operating system still a real (read: certified OR wholly-compliant to spec [unlike Linux]) UNIX? If so, that is an example of a real UNIX where root has limited power.
passwd
is SUID. I feel that most of these restrictions are placed by the utilities and filesystem permissions rather than "the OS", but there are some assumptions "the OS" makes (e.g. the init system is run as UID 0)â Fox
Oct 21 '17 at 14:17
Well, I guess OSX is just nix, isn't it?
â gen
Oct 21 '17 at 14:22
1
I've been prompted to check. macOS 10.12 and 10.13 on Intel-based computers are still certified by The Open Group. And some parts of the filesystem are non-writable by root under any circumstances on these systems (though you can boot to single-user mode and disable this). That was mostly just a response to your last paragraph
â Fox
Oct 21 '17 at 14:28
Putting a question mark at the end does not of itself turn a declarative statement into a question. If you want your last paragraph to be a question, then frame it as an actual question, not as something that has been incorrectly punctuated.
â JdeBP
Oct 21 '17 at 16:39