Many applications require you to type your password. I had always assumed it was sudo doing it. Perhaps it's something else.nagromme said:I never sudo or use Root anyway, but that was my thought. Apparently Apple decided NOT to alter this, so maybe they need a little bad publicity to change their mind
That is not true. The local administrator ("root") account on Windows NT, 2000 and XP systems does not expire unless a policy is in place to force this.winmacguy said:With WinNT and XP the admin password expires after 30 days forcing you to set another new password as the old one is no longer recognised.
Can I ask a stupid question? This is the second time around that we're doing this thread, and I made some changes on my computer the first time (when I found out I could de-admin my account ).nagromme said:I never sudo or use Root anyway, but that was my thought. Apparently Apple decided NOT to alter this, so maybe they need a little bad publicity to change their mind
This is overkill. There's no need to apply all three suggested fixes.aarond12 said:Defaults:ALL !syslog
If you never use the "sudo" command from a terminal window, then this bug shouldn't affect you.mrsebastian said:i'm totally retarded when it comes to looking under the hood of osx, but doesn't the average user not really have to worry 'bout it, since we never log in as the root user?
Yes, but default Linux distros (at least my RedHat one) has the tty_tickets option on by default and logs sudo activity in the secure log file. So the bug can only affect someone who deliberately modified his sudo configuration to a less-secure model.plinden said:This is exactly the same as in any Linux distro - it's not confined to OS X.
On all UNIX systems, there are some maintenance activities which you need to do from a "root" account. (root being the Unix equivalent of an Administrator on other operating systems.)montex said:I have no idea what "sudo" is, and I don't think I'm alone. It's inexcuseable that the author of this article doesn't explain what they're talking about, but I was hoping that someone on the MacRumors Forums would be kind enough to at least define the term.
Setting up a root account certainly isn't the most secure way to go about it. If you're going to be doing a bunch of root-level work, you can always "sudo bash" to get a root sub-shell. Anyway, that's how I've been doing it.shamino said:This is overkill. There's no need to apply all three suggested fixes.
In particular, tty_tickets is meaningless if you set timestamp_timeout to zero.
FWIW, all I did on my system is set timestamp_timeout to zero. For those operations where I really need to run a number of commands as root, I simply "su" to the root account.
You're absolutely right on all counts.mkrishnan said:Suppose someone actually writes a fake application installer that prompts you to superuser graphically, or a virus that uses installers as its host. If you believe in the file authenticity to begin with, then even if your account is set to prohibit you from gaining superuser privileges, you will still username/password in to install the software using a user who has sufficient privilege. Aren't you back at square one then? Who cares if sudo only works on a per TTY or per-command basis, without grace? The trojan was the first command to execute the sudo, so it's the one that has the rights, and it can do whatever it wants. Including using its one sudo act to loosen the sudo requirements by replacing the sudo rc file.
So doesn't it all come back to "don't run apps you don't trust" again?