Is this account of root privileges in UNIX correct?

The name of the pictureThe name of the pictureThe name of the pictureClash 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?







share|improve this question
















  • 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














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?







share|improve this question
















  • 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












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?







share|improve this question












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?









share|improve this question











share|improve this question




share|improve this question










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












  • 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










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. The passwd(1) binary can bypass permissions on /etc/shadow because passwd is setuid to root, and thus it can gain root'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 only root can use raw sockets (in particular this is why ping needs to be setuid to root 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.






share|improve this answer






















  • 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


















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.






share|improve this answer




















  • 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










  • Thats a good point. You should edit it into the answer.
    – jdwolf
    Oct 21 '17 at 17:25










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















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






























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. The passwd(1) binary can bypass permissions on /etc/shadow because passwd is setuid to root, and thus it can gain root'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 only root can use raw sockets (in particular this is why ping needs to be setuid to root 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.






share|improve this answer






















  • 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















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. The passwd(1) binary can bypass permissions on /etc/shadow because passwd is setuid to root, and thus it can gain root'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 only root can use raw sockets (in particular this is why ping needs to be setuid to root 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.






share|improve this answer






















  • 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













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. The passwd(1) binary can bypass permissions on /etc/shadow because passwd is setuid to root, and thus it can gain root'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 only root can use raw sockets (in particular this is why ping needs to be setuid to root 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.






share|improve this answer















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. The passwd(1) binary can bypass permissions on /etc/shadow because passwd is setuid to root, and thus it can gain root'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 only root can use raw sockets (in particular this is why ping needs to be setuid to root 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.







share|improve this answer














share|improve this answer



share|improve this answer








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











  • @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

















  • 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
















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













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.






share|improve this answer




















  • 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










  • Thats a good point. You should edit it into the answer.
    – jdwolf
    Oct 21 '17 at 17:25














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.






share|improve this answer




















  • 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










  • Thats a good point. You should edit it into the answer.
    – jdwolf
    Oct 21 '17 at 17:25












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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










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 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
















  • 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










  • 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

















 

draft saved


draft discarded















































 


draft saved


draft discarded














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













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay