You are not logged in.
Pages: 1
Topic closed
I just ran this from an ssh teminal to OSX:
"sudo shutdown -r now"
And then I made up my mind.
Macs rule :)
I use Windows as my main interface, because of the tons for programs you can run on it, but my mind is made up, Macs and OSX rule, and they will always be at the center of my work flow.
how is that any different from:
shutdown -f -r -t 0
Everyone knows macs ruleeee!
ssh is Unix, shutdown is Unix...
So, the Unix carefully hidden in Mac rules!?...
how is that any different from:
shutdown -f -r -t 0
I dont know.
I was just impressed by the way the mac handled the shutdown on-screen.
No ugly windows closing and stuff, the screen was just dimmed (sem-transparent gray layer) and the rotating throbber, the same one you see on system startup, displayed until the computer was shut down.
ssh is Unix, shutdown is Unix...
So, the Unix carefully hidden in Mac rules!?...
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.
OSX takes that away, while leaving some of the good stuff.
Last edited by rolf (April 5 2010)
i wonder what init 6 or init 0
does on a mac
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"
(uh, sorry, btw, this thread should have been in "Software")
Last edited by rolf (April 5 2010)
sudo is really against my understanding of "unix security".
But having used Linux for so many years, I hope I can try OSX someday.
sudo is really against my understanding of "unix security".
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 wrote:sudo is really against my understanding of "unix security".
Shouldn't be. I find it best to just allow sudo/su only for a group of users while disabling root login over ssh.
you can restrict 'su' usage.
But 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 /* ?
3. If 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.
To 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.
The 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.
Last edited by hussam (April 12 2010)
But 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 /* ?
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.
If 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.
why would one care for securing/hardening a server if s/he's not the administrator ?
To 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.
You are assuming that the attacker knows or can guess the user that has full or some root privileges via su/sudo.
The 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.
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.
Cheers.
BTW, su -c is not available on OSX. sudo is more of a standard and available on all platforms.
Pages: 1
Topic closed