The remaudio driver is mandatory. The other is optional. It packs the dispatcher code used so the other driver may register.
This driver virtualize access to the file /dev/fd0 and the various sound device files (/dev/audio, /dev/dsp, /dev/mixer) and the cd-ROM (sound CD only)
When Virtualfs is enabled, you can use unmodified sound utilities (including those dealing with the cd) and the sound card on your workstation will be used instead of the one on the server. Remaudio was built to support X terminals.
Persmount stands for "personal auto-mounter". It virtualizes access to the floppy and the cd-ROM under the directory n/a: and n/cdrom. It does this without any configuration. It works either on a workstation or an X terminal, accessing either the local or the remote device based on the X DISPLAY environment variable.
Persmount also simplify access to personal network volume (Windows shares, Samba shares, Novell volumes) normally accessed using smbmount or ncpmount. The format of this file is simple: One line per volume you want to access. Comments (using the pound character) are supported. Each lines goes like this:
The actual mount is not done in the n directory. This is generally done in the .n directory (created on the fly). Here is an example (folded in two lines for this document)
server .n/server virtualfs-xsmb --server server \
--share some_share --mountdir .n/server
You can use any mount command you want. The virtualfs-xsmb command is just a shell wrapper which execute the mount in a small xterm window, so you can enter the password. The mount is perform in the $HOME/.n/server. But you access the file in $HOME/n/server.
This dual directories setup is there to allows you to set your current working directory in $HOME/n/server, but still be able to umount (if needed) and re-mount the network volume.
Here is another example to access a Novell server:
server .n/server virtualfs-xncp --server server \
--share some_share --mountdir .n/server
The virtualfs-xsmb
and virtualfs-xncp
are small
wrappers running smbmount and ncpmount in an xterm so you can
enter the password. It is expect that those utilities will become
more sophisticated, potentially exchanging passwords with
a password server, storing and retrieving encrypted password
in a files (to avoid retyping password again and again).
AclFS is now operational. Some more testing is needed, but it already shows what it can do. So here is a small introduction to AclFS.
AclFS relies on a new feature available in kernel 2.2 but not in 2.0. This is called "credentials passing" and allows one client to reliably identify itself to the aclfsd server. This one knows, for each request, the user id, the group id and the process id of the client. Based on this information and the exact request, it grants access or not.
AclFS lets you assign quite a few different privileges. Here they are
This is a pseudo privilege. It grants all privileges, including the security sensitive ones such as chmodany, chownany and chmodsuid.
This is a pseudo privileges. It is equivalent to ALL, but excludes all security sensitive ones. This is the privilege you normally grant to a user who is allowed to fully control the content of a project.
Append to a file.
Change the Unix permission bits of a file or directory owned by the user.
Do a chmod on file you do not own. This pretty much gives super-user privilege. Security sensitive. Beware!
Do a chmod with one of the special bits (setuid, setgid, ...) on. Security sensitive. Beware!
Do a chown on file you do own. This allows you to change the group to one group you are already a member.
Do a chown on file you do not own. This pretty much gives super-user privilege. Security sensitive. Beware!
Create files.
This privilege is not implemented yet. It relies on the fexecve system call, not available yet in linux.
Create hard links.
Create directories.
This is not implemented yet
May change the content of a file. The write attribute combined with the create attribute, but without the overwrite attribute allows one to create file, but one shot only.
May read a file.
Read the content of a directory. You may be unable to browse a directory, but may be able to (blindly) access files inside that directory (if you know the name).
Read the "value" of a symbolic link.
Rename a file or directory.
Remove a directory.
Obtain specification about a file or directory (size, Unix permission bits, ownership, time stamp).
Create a symbolic link. Probably useful to speed up some server such as Apache. If Apache is told not to care about symbolic links (it follow them blindly), it is somewhat faster. By preventing your web author from creating symbolic links, you can use this speedup.
Truncate a file (like erase, followed by a create, except that this is still the same file (same inode)).
Erase a file.
Modify artificially the timestamp of a file/directory.
Write to a file.
..acl files are spreaded in various directories. You generally only need a few as they are inherited bu sub-directories.
..acl files are simple ASCII text file with a relativly simple syntax. The file is free formed and supports comments. Any line starting with a # is discarded. Here is the layout
SOME_LISTS
.
.
FILE_SETTING {
CONTEXT
..
}
.
.
Here is the definition for each item:
A list is a collection of user id, group id and other list separated by a comma. Groups are identified by the @ sign. Lists are identified by the & character. Here is an example:
list special { ted }
list administrators { jack, joe, @admin, &special}
The keyword ALL is used to indicate "everybody".
file pattern {
context name {
...
}
}
A pattern is either a file name or a wild card. Currently regular expression are not supported. * means "every file". Note that the ..acl file is processed sequentially, so the * must be at the end.
A context combine various list with some privileges. The exact privileges granted for a file is the sum of all matching contexts. A context has a name, which will be used for debugging and logging. A context is made of 5 elements:
This is a list of users who will received the privileges. It follows the same syntax as a normal list except it has no name.
grant { joe, @users, &administrators }
This is a list of users who will lose those privileges. (remember that the effective privileges are the sum of all matching contexts).
This is the path of a program (not implemented yet). The context will match only if request originate from a process running this program.
(not implemented yet). The information about the context is passed to an aclfsd module which will add/revoke some privileges.
This provides the list of privileges separated by a comma and ended by a semi-colon. The special keyword ALL means all privileges (very very dangerous) and the keyword MOST means most privileges normally grant to a user. Here is an example:
rights read,stat,readdir;
The operator not (quotation mark) lets you substract privileges.
rights ALL, !chmodsuid,!chmodany;