how is that any different from:
shutdown -f -r -t 0
shutdown -f -r -t 0
I dont know.BashLogic wrotehow is that any different from:
shutdown -f -r -t 0
I would have said unix rules if the GUI part wasn't that buggy, disorganized and generally cheap. And that is without mentioning the packaging system. And half the OS functionality which is implemented through bash scripts.razm wrotessh is Unix, shutdown is Unix...
So, the Unix carefully hidden in Mac rules!?...
rolf-macbook:~ rolf$ sudo init 6;
Password:
sudo: init: command not found
rolf-macbook:~ rolf$ init
-bash: init: command not found
rolf-macbook:~ rolf$ telinit
-bash: telinit: command not found
rolf-macbook:~ rolf$ runlevel
-bash: runlevel: command not found
rolf-macbook:~ rolf$ ls /etc/rc*
/etc/rc.common /etc/rc.netboot
rolf-macbook:~ rolf$ apropos runlevel
runlevel: nothing appropriate
rolf-macbook:~ rolf$ apropos launchd
launchctl(1) - Interfaces with launchd
launchd(8) - System wide and per-user daemon/agent manager
launchd.conf(5) - launchd configuration file
launchd.plist(5) - System wide and per-user daemon/agent configuration files
ntpd-wrapper(8) - Wrapper for ntpdate/ntpd called by launchd
rolf-macbook:~ rolf$ man launchd |grep init
rolf-macbook:~ rolf$ man launchctl |grep init
It seems like the runlevel stuff has been removed and replaced with apples "launchd"Shouldn't be. I find it best to just allow sudo/su only for a group of users while disabling root login over ssh.hussam wrotesudo is really against my understanding of "unix security".
you can restrict 'su' usage.LB1938 wroteShouldn't be. I find it best to just allow sudo/su only for a group of users while disabling root login over ssh.hussam wrotesudo is really against my understanding of "unix security".
Very cute. look hussam, IMHO what's important here is that you know how to limit access to these tools correctly.You can use su instead but with servers that have more than one admin sudo proves very useful.hussam wroteBut why use sudo?
1. You can use su -c 'command' instead.
2. You really don't have the root password to your own machine? Or are you afraid using su will make you accidentally rm /* ?
why would one care for securing/hardening a server if s/he's not the administrator ?hussam wroteIf you don't have the root password to a certain machine at work for example or your parent's machine, there is normally a good reason. If this isn't your machine, then leave administration to the machine's administrator. Linux is a multi user operating system. You can fully function on it without needing admin rights. If something needs admin privileges, call your administrator.
You are assuming that the attacker knows or can guess the user that has full or some root privileges via su/sudo.hussam wroteTo be honest, I don't know the backend mechanism behind sudo but it allows you to optionally have more than one user to use their own passwords to run stuff as root. That means more choices for passwords can be compromised to gain root privileges instead of just the root password.
That's (more or less) the whole point behind allowing sudo/su only for a group of users while disabling root login.I'm really glad you figured it out.hussam wroteThe ONLY good thing about sudo that I can think of it removes the ability to crack root password because if you use sudo, you most likely have root password disabled. This means that an attacker has to know the list of sudoers (it's called sudoers?) to know who's password to crack. On ArchLinux for example, if I log into husssam instead of hussam, it (pam?) won't tell me that there is no husssam user but simply that the password is incorrect.