Longhorn to use UNIX-like User Permissions 697
destuxor writes "After years of Windows users abusing administrative accounts out of necessity, Microsoft promises that Longhorn will make better use of user permissions in what sounds exactly like what UNIX/Linux users have been doing for years. Hopefully this will fix the long list of applcations that cannot be run by a Least-Privilege User Account (LUA) while giving a much-needed security boost. Too bad "MS-root" can't watch over your grandmother when she opens emails."
Logo Program (Score:3, Interesting)
If this is the case, then users will once again become used to just allowing any old piece of software to install with higher privileges, totally defeating the purpose of this.
How many people do you think abort the installation of unsigned drivers, even when XP warns them that they are unsigned. I'd presume it is a very high percentage.
You can lead a horse to water, but you cant make it drink.
Re:Logo Program (Score:5, Informative)
Re:Logo Program (Score:5, Insightful)
Re:Logo Program (Score:5, Insightful)
Re:Logo Program (Score:4, Interesting)
I prefer to continue installation and have a functional system with the latest drivers than to run a ms certified box(driver certs never guaranteed them to not bsod either).
Re:Logo Program (Score:5, Interesting)
The percentage might be higher if the signed-driver thing didn't seem to be used for Microsoft's anti-competitive purposes. Or does no one else remember the fiasco where Windows would complain when you tried to install certified drivers from Nvidia, and instead direct you to install a Microsoft-altered version of the driver with crippled OpenGL?
Re:Logo Program (Score:5, Informative)
So basically, there were conspiracy theories that it was done on purpose, but nothing definitive. Seriously, am I the only one who remembers this? I wasn't even sure it this behavior ever really changed, but it was enough to convince me to always get drivers from the manufacturer (not MS) and ignore the driver signing warnings Windows threw up.
Re:Logo Program (Score:3, Insightful)
Re:Logo Program (Score:5, Insightful)
Tons of software from MS & others on Windows won't work correctly unless user is admin (and support for su equivalent from Windows is weak).
It is like running everything as dba, sure its convenient, but you are just begging for trouble. Worse, when all software is written assuming dba, changing it to run as a regular user is painful. This is the same situation as most windows software is in. Pain will be worse the XP/SP2 by far.
MS should also added chroot to Windows if they are serious about security. Such a simple concept, such a valuable addition. Of course, much windows software goes boom if you introduce chroot, but they should still add it to Windows.
Re:Logo Program (Score:3, Insightful)
My network has everyone run as User, even the developers. All the tools and programs run just fine with a tweak here or there.
Re:Logo Program (Score:5, Informative)
1) HP scanner software - as administrator, works fine. As user, press a button on the scanner and the software can't find the scanner (!).
2) Norton Systemworks - as administrator, updates just fine. As user, can't run updates.
3) Turbotax. Same as Systemworks.
And that's just this week!
Re:Windows != Unix (Score:5, Insightful)
The broader concept is that of putting processes in little restricted-filesystem "jails," which is perfectly applicable to Windows. A process could think that it's dealing with C:\blah when it's actually in C:\Program Files\Applications\Thing\blah. Expanding on the idea, you could expose a CD drive, but keep the DVD burner hidden, and so on. Perhaps you could even hide your Internet connection from a less-than-totally-trusted process that shouldn't need it.
Re:Windows != Unix (Score:3, Insightful)
I would love to have the OS install an application, and then put restrictions on it. Games do not need to know what's in the "My Documents" folder; a Word processor should not be able to take over the screen like a game does. So we need to put applications within groups, and put default permissions on them (which the application can overwrite with the permission of the user).
Types of
'User' attitudes (Score:5, Insightful)
I think that it's a good start and may well make a big difference in companies which use Windows as their desktop platform and have system administrators who can control user accounts.
This section from the article seems to have a good point: A strictly enforced LUA model could make it harder for worms and viruses to take over Windows systems. But Microsoft may have a tough time changing user and developer behaviour, even with new features that support the LUA regime in Longhorn, experts warn.
On home systems, we still currently have enough problems trying to convince people not to open dubious attachments, or with people giving sites permission to install practically anything on their machines. It will take a big shift in attitudes (or Microsoft forcing the user to jump though hoops) to make many home users have anything but admin-privilege accounts.
Home (Score:5, Insightful)
I'd also like to point out that I've been following all of the suggestions and tips on
Thanks guys!
Re:Home (Score:5, Interesting)
I'd return the game to the manufacturer and tell them that was not one of the requirements on the outside of the box and you do not have access to play the game under an admin account. There's no reason a game should have free reign of a system.
Incidentally none of my games on OS X require superuser or even an admin account. Although they require it for installation if you install anywhere else but ~/
Re:Home (Score:5, Funny)
Would that game be Breakout, SuperBreakout, or Photoshop?
Re:Home (Score:3, Informative)
Re:Home (Score:5, Insightful)
As for the rest, no it is not harder to muck up a *nix system than windows, it is just much harder to configure and run a Windows NT/2K/XP system with multi-user priveleges. This is not due to the base OS, which has all the necessary support. It has been bad policy on MS' part by failing to standardize, promote and enforce these requirements in applications. Because of this, application developers (MS included in many cases) take the easy way out and build software that requires admin privs.
Please, do some basic fact checking in the future. Your entire post was very deceptive.
Re:Home (Score:4, Informative)
Just because marketing says it's "new technology" doesn't make it so. NT originally referred to the codename N-10 Intel i860 CPU that it was going to run on.
If I run a malware email attachment as a normal user on my Windows box, it can damage at most that user's profile. That user doesn't have permission to write to anything outside their profile, and so can't damage anything else. Before it can even run, the directory or hash for the binary can't be on SRP [microsoft.com]'s blacklist and the user needs file execute permission.
Although SRP wasn't introduced until XP, everything else has been true since the first version of NT. Show me malware that can bring down an entire Windows system when run as a normal user.
If you're running it as admin, then that's the first problem, isn't it?
Re:Home (Score:3, Informative)
Then you would be correct. Many of the original NT designers worked on VMS at DEC, including their lead architect.
Here's the story: http://www.windowsitpro.com/Articles/Index.cfm?Iss ueID=97&ArticleID=4494 [windowsitpro.com]
Re:Home (Score:3, Interesting)
Games like Abuse do this in Linux and it's always getting new exploits. How many game developers are dedicated to tightening down the security of their code?
Re:Home (Score:5, Insightful)
Will someone tell the reason why on G-d's Green Earth that a typing tutor requires Admin?
The only thing I can think of is sloppy programming, writing to Program Files or to HKLM, instead of C:\Documents and Settings\{user}\Application Data or HKCU
Re:Home (Score:3, Funny)
Re:'User' attitudes (Score:5, Insightful)
On the other hand, perhaps people will end up getting too used to typing in the password whenever it's presented.
"Installer? Check! Installer? Check! Virus? Check!"
Re:'User' attitudes (Score:5, Insightful)
Were it to pop up at an unusual time, I'd think a decent number of people would be suspicious. And for those that weren't, it would at least give them something to reference back to as to "where they went wrong". Problem with Windows is that the "security" fails silently, and soon you have a compromised system and no idea how it got that way.
Re:'User' attitudes (Score:4, Insightful)
"Installer? Check! Installer? Check! Virus? Check!"
I think the more disconcerting possibility is a shareware or other program that mimics the password dialog and sends the results off somewhere. People have a remarkable tendency to use the same password for everything. This could be a boon for password farming.
Jedidiah.
Re:'User' attitudes (Score:3, Insightful)
Re:'User' attitudes (Score:5, Insightful)
And I think that, right there, that's the problem many of us have with Windows' security (you know, when you hear all the MS-bashing about bad security?). Microsoft has sought to appease users/developers who don't understand/care about security measures, and so they've left out the hoops you would have to jump through in order to accomplish things. However, this means that viruses/worms/trojans/spyware/whatever have to jump through fewer hoops as well.
Personally, I'd like to see Microsoft be brave, risk alienating their customers, and do things the right way. The question is, has the bad press about security made Microsoft feel threatened enough to take that risk.
Re:'User' attitudes (Score:5, Insightful)
Some programs refuse to run as root. Some will always warn you. This would be a VERY good thing. There are so many programs that shouldn't be allowed to run as Administrator and, really, should be the norm. User applications should always have this restriction in place. Wordpad can run as Administrator, but MS Word should not. MS Paint can run as administrator, but The GiMP, Photoshop or the like should not!
This would represent a pretty major shift in the user experience, but that shift could be about the only practical way to dig Microsoft's reputation for terrible security out of the hole it's in now.
I'd like nothing more than people to switch to my favorite OS, Linux, but in the mean time, I don't think it's worth all of the suffering that users experience in the mean time.
I think the best mode of operation is for Microsoft to define a white-list of applications that are allowed to run as Administrator and make it a pain in the ass for users to make adjustments to that list each and every time. This would encourage users to run as a user... but again, the problem of developers not updating their coding practices to match will be the biggest hurdle.
Re:'User' attitudes (Score:3, Interesting)
Re:'User' attitudes (Score:3, Insightful)
They key here is that many applications drop their privilege level to some predefined state, ie on many systems this is nobody:nobody.
A white list is no good, it'll just cause a whole bunch of people shouting "I need to run this as admin!"
Just let applicat
Finally... (Score:5, Interesting)
It's about damned time this issue gets addressed. Every day at work I have to fight with this M$ limitation. Chief among the offenders are:
- Kodak Share software
- Autocad
- Any serial port emulation program
- PowerDVD
Most users must be elevated to Power User status on their machines to allow them to do anything nowadays, while there are plenty of programs (like the ones listed above) that will malfunction or simply refuse to work with anything less than full Admin rights. Sometimes, I have no choice but to give a user full Admin rights...I grind my teeth as I do so, knowing full well I'll be called to disinfect the machine of countless spyware programs within weeks, if not days.
Scrap it all and start from scratch (Score:3, Interesting)
Re:Scrap it all and start from scratch (Score:3, Interesting)
Sure you can install Cygwin, but that's not the point.
Re:Finally... (Score:5, Interesting)
That's where I live buddy.
We have a room full of people of varying ability who all have unlimited access because [censored p.o.s. software package] doesn't run otherwise. These guys surf a lot, clicking "yes" on every friggen dialogue box they see... literally can't go a full week without some exploit being loaded.
zero user buy-in for security - When someone shows up to remove the exploit-of-the-week for them, they get is static about "touching my machine". It pains me to be in the same room sometimes...
Re:Finally... (Score:3, Insightful)
For those of you
Re:Finally... (Score:4, Informative)
Re:Finally... (Score:5, Informative)
There's a lot that can be done to enable software to play nicely under a limited user account. Sometime's it's not worth the effort, but in some cases changing permissions on select registry keys and NTFS folders can get things working.
Re:Finally... (Score:5, Interesting)
Re:Finally... (Score:5, Interesting)
- Kodak Share software
- Autocad
- Any serial port emulation program
- PowerDVD
Shouldn't Microsoft Logo certification do something about this? I mean, isn't there a clause saying "Thou shalt let users run thy program withoust being administratorths" or something?
Re:Finally... (Score:3, Interesting)
I know that we use PowerDVD here. We install it under an accout that is a member of the administrator's group. Then we log out and log in as administrator. We copy the profile for the install account to the default user. After that, any one who logs into the machine can use PowerDVD, even though th
Re:Come on over to Linux! (Score:5, Informative)
You do not have to be root to mount anything. That's what
Most programs can be installed as a regular user under $HOME. I've done it many times on systems where I have no root access. This includes everything from Lua to GTK+. In fact, very few Linux programs require root access to install and use properly.
Either you haven't used Linux, or you haven't bothered to learn how to use it properly.
Not to nitpick,but... (Score:3, Informative)
Most distros use the owner flag instead and set ownership of the device in a script when logging on from the console. There is no good reason to allow someone who isn't actually sitting at the console to mount or unmount removeable media, and plenty of reasons not to.
As far as installing as a regular user, you are absolutely right, as long as the program doesn't want to use ports under 1024.
Re:Come on over to Linux! (Score:3, Informative)
You have to be root to install almost anything.
Yes and no, some programs allow you to install to your home directory and then you don't need any permissions. Other than that it's the same for any OS, windows included.... it just happens to be that with windows everyone's usually an admin.
You have to be root to mount a CD-ROM, USB device like a dongle or camera,
Re:Come on over to Linux! (Score:3, Funny)
OSX/FreeBSD: admin == cattle rancher
VMS: User == Ameoba
VMS: admin == Crazed Hermit
Re:Come on over to Linux! (Score:5, Funny)
They say you can hear his screams of "thread-level security" echo through the halls.
Re:Come on over to Linux! (Score:3, Insightful)
The first bit can be worked around using LD_LIBRARY_PATH, but the latter cannot.
Memories (Score:5, Interesting)
I recall a few years ago when all applications even MS Office came with this type of documentation so that Netware administrators could install the software and configure the "rights" properly.
I had recently encountered a few Windows applications where permissions were a problem and I was reminiscing about just that. Serendipity?
What worries me about manifests (Score:5, Insightful)
But here's something that worries me more about manifests:
Based only on this part, it appears that an application manifest must be published by an entity that can afford three figures USD per year for a code signing license. Developers of free software and proprietary freeware often cannot afford this annual fee. My worry is that Longhorn Home Edition may not permit users to install customized deployment manifests, locking users into using only programs with an application manifest, that is, proprietary commercial software.
Re:What worries me about manifests (Score:3, Insightful)
Not necessarily - I assume that the certificate an IT department uses to sign code will only need to be trusted within the company network. Windows Server is shipped with a certification authority software, and it is a (relatively) trivial task to create certificates that are trusted by all machines in a domain.
Of course... (Score:5, Insightful)
The problem has never been a lack of permissions in NTFS, just that no one uses them well.
Re:Of course... (Score:5, Insightful)
Re:Of course... (Score:3, Informative)
It's not really too wierd- it's actually a preview of the "remote attestation" features you may get from "Trusted Computing" next decade.
Battlefield 1942, like all online games using the PunkBuster anti-cheating library [evenbalance.com], needs admin rights so that it can examine every other program you are running, in case any of them is meant to help you cheat.
By running a game like that, you are not only giving that software full control of your computer, but al
A step in the right direction but.. (Score:5, Interesting)
Re:A step in the right direction but.. (Score:4, Informative)
The ability is already there in XP to run at lower permission levels for most applications, it's just that few developers have properly coded for it, as they assume the user will be administrator. I would say that 20-30% of this problem is the developers fault, because the tools are there.
Re:Swing and a miss... (Score:5, Insightful)
Re:Swing and a miss... (Score:3, Insightful)
What's the difference when you look at the end result? Very little. Users are still able to install Banzai Buddy, Gator, My Cool Search, $20/min. dialer programs, etc. The only difference is that instead of ghosting to restore a hosed system, you only have to delete the users profile/home directory after backing up the data files. Big whoop. You just saved a 1/2 hour
Re:Swing and a miss... (Score:3, Insightful)
What they shouldn't be able to do is harm the system in any way by doing so.
Permission Differences (Score:5, Funny)
They'll be patented.
No, Unix uses Windows-style permissions (Score:5, Funny)
http://taint.org/2004/08/20/024522a.html [taint.org]
--
Check out my music video! [mp3unsigned.com]
LUA? (Score:5, Informative)
--
Evan (Really nifty language)
Years? (Score:3, Insightful)
XP does that. User permissions are not the problem (Score:5, Informative)
The problem with Windows permission management is that a) it is completely hidden from the casual user, b) there are no guidelines how applications can be made to work with restricted privileges and programmers are too lazy to figure it out themselves and c) the default XP install makes everybody an admin, so there is very little incentive for application programmers to get it right.
Glad to see a first step.. (Score:3, Insightful)
Years behind (Score:3, Insightful)
I guess what they'll have to be innovative at is implementing it in such a way that it'll be secure, without breaking old software, but breaking old user/developer habits which caused the mess that requires them to implement this now.
Re:Years behind (Score:5, Funny)
M$FT is innovative in the realm of the MS Windows OSes. It does a better job of adding new innovative features to various MS Windows OSes better than anyone else does.
It's a very narrow scope.
UNIX-like? (Score:5, Insightful)
There's nothing inherently UNIX-ish about not giving normal users administrative privileges. Unless you're defining UNIX as any multi-user operating system. The idea of limiting normal users is standard in any decent multi-user operating system.
Not Permissions, Just Common Sense Default ACLs (Score:5, Insightful)
One, they are pushing for 3rd-party developers to finally stop requiring simple apps like kid's software and low-end desktop publishing to be run with escalated privileges.
I mean, these application developers have had since '98 or '99 to work this out. But Window's lax defaults and lack of user education didn't force the issue. Microsoft is finally,
Two, it is Microsoft finally realigning their default ACLs to be at once more secure and more common sense.
It makes no sense for a home user to not be able to control their power settings or change their system time unless they have escalated privileges.
Really, this isn't so much Windows following UNIX as it is Windows following OS X.
Finally, and this is IMHO, going to a permission model would be a *huge* step backwards. I know UNIX die-hards will flame me for this, but it is my experience that ACLs are much more flexible and lucid than permissions.
Re:Not Permissions, Just Common Sense Default ACLs (Score:5, Insightful)
About time (Score:3, Insightful)
Are Unix permissions fine-grained enough? (Score:5, Insightful)
Just as the login process forks and drops its root privileges before running your shell, the file manager or window manager would fork and drop its full user privileges before running an application that was supposed to wear a certain hat.
Re:Are Unix permissions fine-grained enough? (Score:5, Funny)
On UNIX we call this "groups" it's fabulous.
Re:Are Unix permissions fine-grained enough? (Score:4, Insightful)
Now that's certainly untrue -- you can only assign at most three different permission sets for three different groups of users to a given file. "rwx" would allow eight different permission sets though. You can't, for example, assign "r--" to paul and john, "-w-" to lisa and mel, "r-x" to john and sue, and "---" to anybody else.
How often this is really needed is another question though.
Windows biggest problem (Score:5, Insightful)
It has been this way from the beginning... as far back as I can see, developers skirted the BIOS because BIOS calls were too slow -- that was back when the BIOS was part of the OS. This is not a Microsoft problem, but it adds to understanding of how the culture evolved. "Forget about standards and interoperability, we need to deliver performance!" The error in judgement has been costly.
Today developers continue to write code that uses and exploits bugs and irregularities in the MS Windows operating system environment. If I learned nothing else from reading the comments found in the Windows Source code scandals, I learned that Microsoft became obliged to add code to emulate bugs and irregularities for specific applications to continue to run properly. In a perfect world, the app writers would write code using the APIs as documented. (And when bugs and irregularities were found, Microsoft would FIX them to discourage developers from utilizing the strange or buggy behaviors)
Developers should be mature enough to realize that any bug or irregularity found in an OS API should be considered subject to change and could break their software once it is fixed. It kinda bugs me that these "paid professionals" were and continue to be so short-sighted.... (meanwhile, these Open Source Amateurs rely almost exclusively on documented API functions and features simply because bugs and irregularities are often fixed quickly enough that to write code against them would mean they would need to update their code AGAIN.)
I think this kind of speaks volumes about where the real weakness in commericial software development lies -- in the motivation.
Re:Windows biggest problem (Score:3, Insightful)
When Win9x/FAT32 ruled the earth there were no protected directories and everyone, including Microsoft, tended to have writable files everywhere. A lot of programs saved their settings to files in their program directory, which seems bad until you realize that most of the rest wrote to an INI file in the Windows directory. But there were plenty of examples from Microsoft that did similar thing
Re:Windows biggest problem is Microsoft (Score:5, Insightful)
It bloody well is a Microsoft problem. They had the ability to improve the performance of the BIOS, ANSI.SYS was frequently ten to a hundred times faster than the BIOS on a typical computer... all they needed to do was intercept the BIOS calls and perform the same operations they did with ANSI.SYS and they would immediately remove any need for people to go around them.
But they didn't. So your choice was ANSI.SYS, or direct hardware access. I went with the BIOS for my terminal program and half my code was "curses" style optimizations to avoid making extra trips into the BIOS
Similarly, the current mess with applications needing to write to %SYSTEMROOT% to install is Microsoft's fault, because for many years they recommended that applications do that... as near as I can tell so they could ship DLL updates through application vendors instead of coming up with their own update mechanism. The result of that? Administrator-level installers, DLL Hell, and viruses being REINSTALLED back into %SYSTEMROOT% by the system restore tools they created to try and work around the problems...
Not Microsoft's fault? Like hell it's not!
Permissions in the Home vs. in the Workplace (Score:5, Insightful)
While this will be a certain benefit to corporate environments with IT security policies and IT departments to come install/upgrade software for employees while at the same time ensuring that new version of FreeCell you got from a friend doesn't infect the whole corporate network, the issues become more troublesome for home users.
A home user will either end up running their system as an Administrator, thus circumventing the access permissions model, and/or they will become frustrated with the inability to install/update/access/delete files on their own computer.
How many times has the home user faced a property configuration wizard that tells them to contact their "system/network administrator" for more information.
My mother is not a "system administrator", but yet, to change her ISP, she had to put on that hat or call me to talk her through it.
No disrespect to Linux, but Microsoft would do well to study Apple's model for system security on a home implementation. Apple has, successfulyl in my opinion, abstracted much of the user security model to allow the home user to know nothing about CHMOD while still providing appropriate security when needed - like entering an administrative password (SUDOing the application) for installations and upgrades.
Last on the list of needed changes to the windows security model is to provide far more robust error/exception handling when a user does something like tries to rename a file that is open. Consider this closing argument:
"The file cannot be renamed because it is in use by another application."
versus
"The file 'foo.doc' cannot be renamed to 'bar.doc' because it is opened by 'Word.exe' would you like to:
- Cancel the renaming
- Save the document changes in Word and rename the file
- Discard the document changes in Word and rename the file"
Of course Longhorn will be Unix-like... (Score:4, Funny)
Re:Of course Longhorn will be Unix-like... (Score:3, Funny)
How About Better Error Messages? (Score:3, Insightful)
If it were easy to tell what the problem was, it would be easier to have a secure system.
Not good (Score:3, Insightful)
This can only further limit other OS's.
To me it feels more like a race between MS and OSS programmers to get the technology out there to be 'previous art' before we get shut out in the cold by our own legal system.
"Fixing Permissions" (Score:3, Informative)
Anyone seen this fortune cookie before? (Score:3, Insightful)
This is nice and all (Score:4, Insightful)
Ugh, I'm already seeing the problems.
Cowpokes (Score:3, Funny)
Nice to see they're considering adding features added to other OS's 20 years ago, though.
MS pattern: big promises, partial delivery (Score:3, Interesting)
When Microsoft software has an obvious problem that competitive software does not, the general pattern is that a) Microsoft claims the next release will fix it; b) the next release falls far short of a fix but is nevertheless a noticeable improvement; c) applause from Microsoft fanboys drowns out those would observe they still haven't achieved parity with the non-Microsoft state-of-the-art.
Since Microsoft users live in a sealed universe--they're too busy keeping up with security patches, changes in API's, and evolving purchase and licensing plans to have the time to ever use any non-Microsoft software--Microsoft gets away with this pattern of "big promise, partial delivery"
Complaints about Windows 3.0 instability were met by the assertion that you "would never see a UAE in Windows 3.1."
Complaints about FAT fragmentation were met by assertions that NTFS would not require defragmentation.
Comments that Windows 3.X was far less usable than the Mac OS were met by assertions that Windows 95 would be just as good as the Mac.
Complaints that installing software under NT 3.x were met by assertions that NT 4.0 would not require rebooting....
Just proves the old addage (Score:4, Funny)
C'mon, Winamp!! (Score:3, Interesting)
Blah. It's a good thing iTunes rocks.
Re:C'mon, Winamp!! (Score:4, Informative)
Winamp is a TOTAL pain in the ass [webdevlab.com] when it comes to running as a limited user, but there are a few ways to get it to work right without running as admin. The first, obviously, is to install Winamp to your user directory. This is not the most secure method, but with some care it can be (relatively) safe and certainly better than logging on as admin. The other way is a bit more complicated and involves a plugin and directions that can be found here [rosenkeller.org].
Thank God the kids are moving! (Score:3, Interesting)
There were similar problems with Eudora which my wife uses for email. So, she's an admistrator, too. And Eudora had its own headache under XP--she and I could not share mailboxes as we had done under Win98, even if the mailboxes were in a shared directory.
Good thing I have my own Linux box. When the kids and their games leave, I'm getting the Mrs. a Mac and shinning on we're-all-administrators-here Windows for good.
A downgrade (Score:3, Interesting)
a) Run in an unprivileged state until they get a privilege error
b) Determine if they really want to do the thing that caused the error
c) If yes temporarily grant themselves permission to do this thing. This is sort of like sudo but only grants one particular type of privilege not everything at once
d) Try again. If they get another permissions error on another permission repeat steps b and c.
e) Once successful (or they decide not to complete the action) then lower their permissions back down to their normal level.
The closest analogy for people haven't used VMS or a mainframe would be OSX when it asks you specifically before you do an administrative task.
This is way safer than Unix's system of permissions. The problem is that applications just fail for lack of privilege and the interface doesn't make it easy to bump all over the place. Frankly I think adopting the Unix model with less fine grained privileges is a major downgrade to NT. The problem is with the applications (including those written by Microsoft) not the OS.
Re:What? (Score:3, Insightful)
Unix are beginning to get ACLs now with some implementations but I don't ever see it going down to the system files.
Re:-rw-r--r-- (Score:5, Insightful)
Instead, the Windows security model is (apparently) going to be more Unix-like, in that the demarcation between administrator (root) and normal user will be more strict. Mostly, this means making software developers allow their programs to be installed and run with limited permissions, unlike the current admin-fest.
There are many ways that Microsoft could fuck this up, but I hope they don't. Unlike some people, I have no investment in constantly repairing ruined systems.
Re:-rw-r--r-- (Score:4, Funny)
Re:-rw-r--r-- (Score:5, Insightful)
Re:ACLs (Score:3, Insightful)
The article poster's saying "Unix Permissions" was being misinformative; Windows will never use the setuid-user-group-world style perm
ACLs in UNIX (Score:3, Interesting)
Unix permissions _do suck, they're too simplistic and ACLs solve a lot of the problems inherent to it.
The UNIX® permissions model has had access control lists pretty much forever. Every user can belong to one or more lists of users called "groups", and each file designates a set of permissions ("Access Control") for a group ("List"). Some file systems allow for more sophisticated ACL behavior by specifying more than (access control, group) tuple.
But ACLs are broken anyway; the next wave of permi
Re:Permissions - who cares - they need symbolic li (Score:3, Insightful)
Mount points have been supported since 2000 (Score:5, Informative)
Before bashing something you should at least RTFM, otherwise you just look like a typical teenage Linux zealot.