Open directory and passwd permissions

You're getting your terms crossed.

Currently i know that users are stored in "access control lists"

Users are not stored in 'access control lists'.

Access Control Lists (ACLs) are used to determine which users have which permissions on specific files and/or directories. They go an order of mangnitude deeper than the traditional UNIX permissions of user/group/other and read/write/execute.

which are in /etc/master.passwd and /etc/passwd

In either case, these files are not related to access control lists. They hold the account data used when the system is in single user mode. Outside of that (i.e. in normal operations) user data is stored in NetInfo or Open Directory (depending on the OS version).

I'd like to know how to edit permissions of my user (and other users as i am the root) in my open directory account

If you're talking about configuring ACLs for files on your system, that's done via the chmod command.

I don't know where is the Open Directory application.

There is no 'Open Directory application'. It's a server-based process that manages user accounts, and isn't an application that you can double-click.

I read that any file which return a '+' when ls -l depends on them.

The + indicates that the file has an access control list associated with it.

Besides some of them end with an at '@' instead of '+' (i don't know what that means).

The @ indicates extended attributes (something different from ACLs). From man ls:

If the file or directory has extended
attributes, the permissions field printed by the -l option is followed by
a '@' character. Otherwise, if the file or directory has extended secu-
rity information, the permissions field printed by the -l option is fol-
lowed by a '+' character.

So the question is, what is it you're trying to do?

If you're trying to view the ACL associated with a file, use:

# ls -le file1
-rw-r--r--+ 1 juser wheel 0 Apr 28 14:06 file1
owner: juser
1: admin allow write

If you're trying to set an ACL on a file:

# chmod +a "guest deny read" file1
# ls -le
-rw-r--r--+ 1 juser wheel 0 Apr 28 14:06 file1
owner: juser
1: guest deny read
2: admin allow write

(the above is taken directly from man ls.

Note that this form of ACL is specific to Mac OS X. This is not standard UNIX permissions and therefore won't translate to other OSes.

1.Where are user accounts stored? I mean, when i login with several accounts, each of them is a different user. Where does the system save those users list and passwords of so the people can login with their name/password?

They're stored in an internal database that isn't (typically) user accessible. System Preferences -> Accounts (for Mac OS X client) and Workgroup Manager (for Mac OS X Server) read and write to this database, as do various command-line tools.

The actual data is stored in /var/db, but sholdn't normally be accessed directly.

2. Does OS X use old 'traditional unix permissions' in any way?

Yes. That's the default unless there is a more specific access control list applied.

3. Which deeper level go them to?

I don't understand this question.

4. What does single-user mode? When i'm not attached to a lan network?

No. Single user mode is a special, lightweight environment, typically used for debugging and troubleshooting. No network access is permitted, so no remote users can log in, nor do most services run. It's most commonly used when you need to fix problems on the server that can't be done while there are active users/processes running.

5. Is NetInfo an 'old' version of Open Directory? (i mean, my netinfo isn't in the usual path people report on websites. I foud it at Developers folder.

NetInfo was the standard up to Mac OS X 10.4 (or was it 10.3? I forget now). 10.5 moved entirely to Open Directory.

6. Then chmod, and other commands like addusr, chown, and so on work on ACLs instead of old permissions, right?

chmod is used to set both traditional UNIX permissions as well as ACLs (Apple extended their version of chmod to understand both permission models.
addusr doesn't exist in Mac OS X
chown changes the ownership of the file, but doesn't have any bearing on permissions.

Which are those Open Directory processes?

The primary one is /usr/sbin/DirectoryService but it's a background process and not something you can launch manually.

Directory and Directories Utility

Directory is a kind of centralized address book - it lets you look at certain user data in the Open Directory database.

Directory Utility is an application that you use to bind your client system to a directory server - i.e. you use this app to tell the system which directory server(s) to use for authentication.

10. What 'extended' permissions mean?

I thought we'd covered this. There are two kinds of permissions system used by Mac OS X. POSIX (aka 'UNIX') permissions, and ACLs. "ACL" and "extended permissions" are the same thing.

And extended attributes (and why they don't belong to ACLs)?

because extended atttributes are not, necessarily, access control related.
For example, there's an extended attribute that indicates a file was downloaded off the internet. The Finder uses this to post the warning when you launch a downloaded app for the first time. This attribute has no bearing on access control lists and therefore it isn't in the ACLs.
Other applications can create their own attributes - just additional data they want to store alongside the actual file contents.

11. Why aren't the same as unix? I've read many manuals where linux users use chown and those commands.

Hmm, I thought we'd covered this, too.

UNIX permissions were devised in the 1970s when the world was a lot simpler.
They have three levels of 'ownership' - a user, a group, and everyone else.
For each level you can define permissions to read, write, and/or execute the file. That's it.
That's not sufficient for modern security models, but it's legacy that just about everyone understands.

ACLs take the concept an order of magnitude further. In addition to the POSIX standard you can decide whether a user can delete a file, read or write attributes, change permissions, and more, as well as supporting inheritence.
In addition to that, There can be multiple ACL rules applied to a file. You could have an ACL that defines any user in the 'staff' group as being able to read/write a file, while John or Dave can also delete the file, and Jane can do that as well as manipulate the attributes and change permission and any non-specified user can only read the file. That's a combination that would not be possible under standard UNIX/POSIX permissions.

So think of UNIX/POSIX permissions as being 'old school'. The lowest common denominator, but also the least flexible. ACLs are the modern equivalent, but POSIX permissions are supported, too.