Access Control: take them from Novell Netware

Posted Nov 18, 2010 9:41 UTC (Thu) by zmi (guest, #4829)
In reply to: Access Control: take them from Novell Netware by Fowl
Parent article: Ghosts of Unix past, part 3: Unfixable designs

> Did I miss the explanation of why Windows ACLs are so horrendous?

Maybe you've never had a big file system. Take this example:

Company with 900 employees, 40TB storage in about 40 departments, with a total of 100 million files.
Now you have a hierachical structure, each dept. has it's own dir, and below that you have other dirs shareable with other depts.

And then someone needs to set a new permission for a top-level dir. Both Unix and Windows ask to write those permissions to all files below that dir. If there are 10 million entries, the session will be blocked for a pretty long time.

Novells Netware didn't have that: Set a new permission, done within the second. I don't know how they stored permissions, but it never depended on the amount of data below that dir.

Also, in Unix and Windows there's a mix of permissions from a share and permissions to a file. In Netware you assigned a right, at that's it. Much easier to review.

Access Control: take them from Novell Netware

Posted Nov 18, 2010 10:14 UTC (Thu) by Fowl (subscriber, #65667) [Link] (8 responses)

> If there are 10 million entries, the session will be blocked for a pretty long time.

Ah, I get you. It's the implementation that's the problem, not the concept.

> Both Unix and Windows ask to write those permissions to all files below that dir.

I'm fairly certain Explorer (the Windows shell) uses the most naive method possible for applying permissions.

> Also, in Unix and Windows there's a mix of permissions from a share and permissions to a file. In Netware you assigned a right, at that's it. Much easier to review.

For as long as I can remember giving full access to shares to "Everyone", and then using filesystem permisions has been the recommended practise. It is useful occasionally for enforcing "no remote access" policies, etc.

Access Control: take them from Novell Netware

Posted Nov 18, 2010 10:42 UTC (Thu) by zmi (guest, #4829) [Link] (4 responses)

> For as long as I can remember giving full access to shares to "Everyone", and then using filesystem permisions has been the recommended practise.

And it brings the feature "you see the share, but clicking on it tells you you can't access it". Again it's the implementation that's wrong: If I have no right on it anyway, don't display it. Seems to be a lazyness of programmers to have chosen this way.

Access Control: take them from Novell Netware

Posted Nov 18, 2010 13:55 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (2 responses)

And it brings the feature "you see the share, but clicking on it tells you you can't access it". Again it's the implementation that's wrong: If I have no right on it anyway, don't display it. Seems to be a lazyness of programmers to have chosen this way.

Counterpoint: /bin/ls lists the names of directories not owned by the user it's running as whose access control mode is 0700 (user rwx, all others forbidden).

Access Control: take them from Novell Netware

Posted Nov 18, 2010 14:04 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)

Counterpoint: /bin/ls lists the names of directories not owned by the user it's running as whose access control mode is 0700 (user rwx, all others forbidden).

Which is perfectly correct behavior according to the way UNIX permissions are defined. The ability to list names in a directory is controlled only by the r bit of the directory itself.

Access Control: take them from Novell Netware

Posted Nov 18, 2010 14:16 UTC (Thu) by zmi (guest, #4829) [Link]

ls is a technical unix command, not a user tool (which "clicki-clicki" mouse user knows ls?). ls must show everything, and it follows the kiss principle (keep it small and simple).

Using a graphical dir browser like Dolphin could hide such unreadable contents, that would be nice, as normally users don't need to see that. Should be a config option.

Browsing a server over the network is about 20 years younger "command", solving completely different needs, and it would help security a bit if shares not accessible are not seen by a user. But by the time Microsoft reinvented networking, they did not have the slightest clue about security (and I'd say that only started with Win7, where a user can work as user not admin). Maybe we'll see that improvement once someone at Microsoft gets the idea. Or maybe the Samba team can implement a setting to hide this, and later MS adopts it as it's clever.

Access Control: take them from Novell Netware

Posted Nov 21, 2010 0:27 UTC (Sun) by Fowl (subscriber, #65667) [Link]

That issue seems completely unrelated.

Access Control: take them from Novell Netware

Posted Nov 18, 2010 17:57 UTC (Thu) by davecb (subscriber, #1574) [Link]

Also from Multics: it is relatively parsimonious, and has the concept of "initial acls", so it really only needs to store acls that are different from the iacl (or from the base acl of the tree).

--dave

Access Control: take them from Novell Netware

Posted Nov 18, 2010 20:38 UTC (Thu) by jra (subscriber, #55261) [Link] (1 responses)

> Ah, I get you. It's the implementation that's the problem, not the concept.

No, with Windows ACLs it's the concept.

Look at this:

http://www.pcguide.com/ref/hdd/file/ntfs/secRes-c.html

as an example. Explain that to a user. Don't forget to include why the sort order of DENY's ACE's depends on where in the file hierarchy they came from.

Good luck ! :-)

Jeremy.

Access Control: take them from Novell Netware

Posted Nov 21, 2010 0:31 UTC (Sun) by Fowl (subscriber, #65667) [Link]

You recurse up the tree, until you find an applicable entry, with deny taking precedence over allows.

How is that complicated?