Unix File / Data Recovery Software - UFS / Vxfs

Unix Wildcard Characters

2006-12-16T14:08:00.002-08:00

Using Wildcard Characters

Sometimes you might want to use a command on several different files. To reduce the amount of typing you need to do, you can use wildcard characters to aid in matching filenames.

?: This character matches any one character.
*: This character matches any group of zero or more characters.

Say you have a directory which contains the following files: `file', `file2', `file3', `fun', `fun2', `mbox', and `readme'. Here are some examples of wildcard use with these files:

% ls *

file file2 file3 fun fun2 mbox readme

% ls f*

file file2 file3 fun fun2

% ls file?

file2 file3

% ls ????

file mbox

The first example shows ls being used with a `*'. As promised, the `*' matched all the files in the directory (all files in the directory have 0 or more characters!). In the second example, an `f' is followed by a `*'. This caused all the files beginning with an `f' to be listed. The third example shows a use of the `?' character. With `file?', only filenames that begin with the word `file' and have one extra character on the end will be matched. Finally, using four `?' characters in a row will match all filenames that are exactly four characters long.

Use wildcard characters with caution. They are often useful but can be very dangerous. When used with a command like rm, you can easily remove all the files in a directory (which is something you probably do not want to do).

Sometimes you might want to use a command on several different files. To reduce the amount of typing you need to do, you can use wildcard characters to aid in matching filenames.

?: This character matches any one character.
*: This character matches any group of zero or more characters.

Say you have a directory which contains the following files: `file', `file2', `file3', `fun', `fun2', `mbox', and `readme'. Here are some examples of wildcard use with these files:

% ls *

file file2 file3 fun fun2 mbox readme

% ls f*

file file2 file3 fun fun2

% ls file?

file2 file3

% ls ????

file mbox

Unix File System Command Summary

2006-12-16T14:08:00.001-08:00

File System Command Summary

Here's a small summary of the commands that are discussed in the following sections. These commands do a variety of file system tasks, many of which are essential to know in order to get by in the Unix environment.

pwd: (present working directory) Prints out the full pathname of the directory you are currently in.
cd directory: (change directory) Changes your current directory. If you don't specify a directory as an argument, cd will bring you back to your home directory.
ls directory ...: (list) Lists the contents of a directory or directories. If you don't specify a directory, ls will list the contents of the current directory. You may also supply filename(s) to ls in order to get more information about files.
mkdir directory ...: (make directory) Used to create a directory or directories.
rmdir directory ...: (remove directory) Used to remove an empty directory or directories (the directories to be removed must not contain any files).
cat file1 ...: (concatenate) Used to view a file or files continuously on your terminal. If you use cat to view a long file, you will have to use C-s to pause the screen and C-q to unpause it (otherwise the file will just zip on by). For files longer than a screen, it is recommended that you use either more or less to view the file.
more file
less file: These two programs will let you view your file a screenful at a time. They both offer special viewing options such as paging backwards through a file and pattern searching. less is the more sophisticated of the two and has features that aren't found in more.
rm file1 ...: (remove) Removes the given file or files.
mv file1 file2
mv file1 ... fileN directory: (move) Moves a file or directory. In the first form, file1 will be moved to (renamed as) file2. The second form will move a number of files into a directory which you specify as the last argument. Note that directory names can be used in place of the filenames in either of the forms, to move or rename directories.
cp file1 file2
cp file1 ... fileN directory: (copy) Copies files. In the first form, file1 will be copied to a file called file2. The second form will copy a number of files into a directory which you specify as the last argument on the command line.
chmod mode file1 ...: (change mode) Changes file permissions. The mode specifies how you wish to change the permissions for the listed file(s).

The Unix Command Line Format

2006-12-16T14:07:00.002-08:00

The Unix Command Line Format

Generally, Unix commands are pretty cryptic and take some time to master. Yet, the format of most commands are very similar. Understanding this format makes learning new commands easy. In the following example, Unix command usage is illustrated with ls, a command which lists filenames.

% ls -al cs111 en104

Breaking down this line, there are three basic parts, which are the same in most Unix commands:

Command: [ls] The command is the program that you wish to run. ls is a command used to list the contents of directories.
Option flags: [-al] The option flags make the program act in a certain way. Option flags are normally preceded with a dash. The flags used in the example make ls print all files in long format.
Arguments: [cs111 en104] The types of things in the argument list will vary from command to command, and will often be file or directory names. The ls command takes file and directory names separated by spaces as arguments.

Different commands use different option flags. For the sake of the simplicity, the option flags, `-al', were grouped together. Unix commands are usually not too fussy when it comes to the order the flags are typed in or how they are broken up. The flags could have also been written as `-l -a'.

Here's another example, using lpr, a command used print your files on the laser printer.

% lpr -Psiskel -h homework

% lpr -h -P siskel homework

% lpr -hP siskel homework

The three sample commands above send the file `homework' to the printer siskel (`-Psiskel') to be printed with no header page (`-h'). Some options, like `-P' take an input word directly after it. Notice that it doesn't matter if you put a space between `-P' and the printer name, but it does matter that you follow the printer name with a space, before specifying the file name(s) to print.

Understanding Directories

2006-12-16T14:07:00.001-08:00

Understanding Directories

As stated in the previous section, directories are like folders that can contain files and other directories. By giving a directory a name that describes what it will contain, you can build a directory structure which will make it easy to find related files later on. Directory structures are most easily visualized using a tree type picture.

The following figure is a diagram of a very simple directory structure.

/ | \

usr | \

/ | \

games bin home

/ \

chuckd ice-t

Figure A

The very top directory in a Unix system is called the ``root directory'' and is signified by a single `/'. From the root directory, other directories branch off and hold everything from the commands you run (bin) to your home directory (chuckd or ice-t).

Types of Files in Unix

2006-12-16T14:05:00.000-08:00

Types of Files in Unix
A file is much like a container which holds various types of information. Unix supports several different types of file, but you will only be dealing with a few of them:

Text Files
These files contain text, and can be created in a text editor, such as emacs. Also known as ASCII files, they contain ASCII codes, which represent the characters you see on the terminal. A text file can be anything from a list of your friends to a C program to a script file. There are a number of ways to view text files. We'll talk more about viewing files later.

Executable Files
These files are commands which you can run from the Unix prompt. They are usually created by compiling a C or Pascal program with gcc or pc. Both compilers generate an executable file called `a.out' by default. By typing in the name of an executable file on the command line, you can run (or execute) that file. Do not try to view these files with cat, more, or less. Doing so can lock your terminal, because executable files contain lots of strange control characters. Also, do not print out an executable file!

Directories
These special files act as folders which hold other files. A directory file contains information about all of the files stored in that directory.

When using the ls -F command to view the files in a directory, files are marked with a distinct symbol that describes the files' type. See Listing Directories with ls, for more information about listing your files.

NAS Network Attached Storage for Small Businesses

2006-12-16T14:02:00.000-08:00

NAS Network Attached Storage for Small Businesses

New Iomega StorCenter Pro NAS 250d Models Feature Hot-Swappable SATA-II Drives for Improved Performance, Network Uptime
Iomega Corporation (NYSE:IOM), a global leader in data storage and protection solutions, today announced the next generation of its popular Iomega® StorCenter(TM) network-attached storage (NAS) devices. These new servers give small and medium business networks improved performance, reliability, and security in a convenient whisper-quiet desktop form factor.

The new Iomega StorCenter Pro NAS 250d Servers will soon be available worldwide in four new models ranging in capacity from 500GB* to 1.5TB*. All models feature the Microsoft Windows Storage Server 2003 R2 operating system, optimized for file and print services across the network. Configuration is virtually automatic with Iomega's Discovery Tool software, and the Microsoft Management Console provides a standard interface for network administration.

"Iomega's new easy-to-use StorCenter Pro 250d NAS appliances deliver on four network essentials that SMBs need in today's data-driven business environment: protecting data, securely sharing data, ease of use and saving users time and money," said Tom Kampfer, President and COO, Iomega Corporation. "These imperatives matter because secure access to corporate data is the lifeblood of a modern small or mid-sized business. By adopting hot-swappable drives and faster hardware in a desktop format, Iomega StorCenter Pro 250d NAS appliances give SMBs and network managers the improved network uptime and data security they need at an economical price. By utilizing Windows Storage Server R2, the 250d offers the reliability and compatibility of Windows with far greater performance than could be achieved in a comparable Linux-based device."

While previous generations of Iomega StorCenter Pro NAS servers have used Microsoft technologies, the new Iomega StorCenter Pro NAS 250d servers are the first Iomega NAS servers offered with Windows Storage Server 2003 R2.

"Small and medium-size businesses face highly competitive environments where growth is critical to survival. Reliable data storage, backup and archive processes are a key to success, but most SMBs don't have in-depth IT expertise," said Bala Kasiviswanathan, Group Product Manager for Storage at Microsoft. "Iomega's next generation StorCenter Pro NAS servers with Microsoft Windows Storage Server R2 give SMBs ideal solutions that are easy to implement and maintain for sharing, protecting and archiving their data."

One of the new systems announced today, the StorCenter Pro NAS 250d 500GB server, also comes with a built-in Iomega® REV® 70GB drive for state-of-the-art server backup and restore operations. Award-winning REV drives and removable 35GB and 70GB REV disks combine the speed and reliability of a hard drive with the removability of tape for lightning-quick backup and recovery.

StorCenter Pro Features and Benefits

The flagship product in today's announcement is the Iomega® StorCenter(TM) Pro NAS 250d 1.5TB Server with print capability. Like all 250d Server products announced today, it uses SATA-II hot-swappable hard drives. Three 500GB 7200-RPM hard drives provide a total capacity of 1.5TB, and hardware RAID options include RAID 5 (striping plus parity), RAID 0 (striping), and RAID 1 (mirroring). The 750GB model uses three 250GB drives and supports the same hardware RAID options. The 500GB models in today's announcement are two-drive models that support RAID 0 and RAID 1, driven by Intel® Matrix RAID technology.

Like the previous-generation 200d series, the 750GB and 1.5TB models in the 250d series feature dual Gigabit Ethernet connections with automatic load balancing and failover, and an external Ultra 320 SCSI connection. A faster Intel Celeron D 352 3.2 GHz processor replaces the previous generation's Celeron 2.5 GHz processor, improving overall performance.

Iomega StorCenter Pro NAS 250d Servers provide broad support for Microsoft file and print services. File services with 500GB models include Active Directory, Encrypting File System (EFS), Volume Shadow Copy Services (VSS), and SRM. Additional standard services with the 750GB and 1.5TB models include Distributed Files System (DFS-N and DFS-R), and File Server Resource Manager (FSRM).

Print services for the 750GB and 1.5TB models include a 5-printer license (upgradable to unlimited printers) for Microsoft Print Server.

For backup and disaster recovery, all Iomega StorCenter Pro NAS 250d models include CA BrightStor ARCserve OEM edition software with disaster recovery, version 11.5, along with EMC Retrospect Express software for client backup and recovery (5-client license included; additional licenses are available).

Compatibility

Iomega StorCenter Pro NAS 250d Servers support clients running Microsoft Windows 2000/XP Home/XP Professional/XP Professional x64, Mac® OS X 10.2.7 or higher, and Linux distributions, including Redhat 9, Madrake 10, Debian 3.0, Gentoo, and FedoraCore 3.

Supported network file protocols include Microsoft, Linux/UNIX, Apple, Internet, FTP, and WEBDAV.

Price and Availability

The StorCenter(TM) Pro 250d 500GB Server with REV® Built-In is now available for $1,999, as well as the StorCenter(TM) Pro 250d 500GB Server for $1,399. The StorCenter(TM) Pro 250d 750GB Server with Print is expected to be available December 30, 2006, for $2,799. The Iomega® StorCenter(TM) Pro 250d 1.5TB Server with Print is also expected to be available December 30, 2006, for $3,999. (All prices are suggested US retail.)

NAS Recovery, NAS Data Recovery, NAS volume recovery, NAS file recovery, NAS Recovery Software
Network Attached Storage Recovery, Network Attached Storage volume recovery, Network Attached Storage data recovery

Unix / Linux Server are more relaiable

2006-12-16T13:48:00.001-08:00

Web Hosting Providers Praise SWsoft Plesk 8.1, for Linux/Unix, Windows Parity
News
Herndon, Virginia - (The Hosting News) - December 8, 2006 - Server virtualization and automation software company, SWsoft, has released its Plesk 8.1 for Linux/Unix and Plesk 8.1 for Windows control panel software, developed to deliver parity, new features, and functionality.

The new software adds to the Windows version many of the features found in the Linux/Unix version, designed to enable web hosting providers the ability to offer comparable solutions to customers on both platforms. Future versions of the software will be released simultaneously.

Lorena Diaz, Product Manager at SWsoft offered, ''Plesk 8.1 marks a major turning point for SWsoft and the hosting market by bringing the capabilities of the Linux/Unix version to the Windows platform. After an intensive product development effort that included the SWsoft Community Technology Preview program, Plesk 8.1 delivers a high quality control panel solution with significantly enhanced customization and management capabilities for providers, resellers and end users.''

Plesk 8.1 for Windows was developed to include functionality -- previously offered only with Plesk 8.0 for Linux/Unix -- to significantly improve ease-of-use and system management for administrators and customers. Plesk 8.1 for Linux/Unix includes several important updates, including improvements to the custom desktop, new user-friendly news management features and support for Fedora Core 5.

Feature highlights include:

• Plesk Desktop – Gives administrators and clients quick access to major management functions and immediate access to mission critical information and statistics.
• Customizable Interface Templates – Enables administrators to customize templates that can be assigned to individual users.
• Plesk Product News - Provides the latest news and information to Plesk users regarding major product updates and improvements.
• Improved Virtuozzo Integration – Delivers seamless integration with Virtuozzo, allowing hosting providers to manage more customers more efficiently. Plesk 8.1 is optimized to operate within Virtuozzo, enabling users to host up to 15 percent more virtual environments per physical server.
• Acronis True Image Server 9.1- Comes integrated with Acronis True Image 9.1, making it faster and easier for administrators to back-up servers and perform system recovery without interrupting operations.
• Autoinstaller V3 – Lets administrators deploy and upgrade multiple servers in an efficient, cost effective manner. The new architecture improves dependencies tracking and increases speed during installation to simplify support of new operating systems.

Craig Rodenberg, Vice President, Information Security, REDPLAID Managed Hosting added, ''SWsoft continues to set the standard for hosting automation and control panels with this latest release of Plesk. By upgrading the Windows version to match the features and functionality of the Linux/Unix version, Plesk 8.1 gives us the opportunity to offer our customers the most advanced control panel solution for both platforms.''

The improved integration of Plesk 8.1 with SWsoft Virtuozzo virtualization software supports SWsoft's OPEN FUSION initiative to move all of its products to a common platform and advance integration among a wide range of systems, third party applications, and custom and in-house systems. Platform benefits include reduced time-to-market for service offerings, more automated and integrated systems with single sign-on, among other solutions.

Plesk 8.1 is available now from SWsoft and its partners worldwide. The upgrade is available at no additional charge to existing customers with subscriptions or the SWsoft software update service.

SWsoft is a recognized leader in server automation and virtualization software. With more than 10,000 customers in over 100 countries, SWsoft's suite of products delivers proven performance, reliability, manageability and value. With offices around the world; SWsoft is a high growth company, funded by Bessemer Venture Partners, Insight Venture Partners and Intel Capital, offering comprehensive solutions – transparently integrated through the OPEN FUSION Initiative - including Virtuozzo, Plesk, SiteBuilder, HSPcomplete and PEM

Sun Solaris less vunerable to data loss

2006-12-16T13:43:00.000-08:00

Making Solaris More Trustworthy

Sun's Solaris 10 Unix operating system got its third major update, and it includes the long-anticipated Trusted Extensions, which replaces the legacy Trusted Solaris operating system.

Discuss this article in the ServerWatch discussion forum

Trusted Solaris Extensions have been in development at Sun for more than a year as a new approach to creating a Trusted Solaris OS.

In September 2005, Mark Thacker, product line manager of Solaris security at Sun Microsystems, explained to internetnews.com that Trusted Solaris has always been a separate operating system.

With Trusted Solaris Extensions, instead of an entirely separate operating system, the extensions are overlays on top of Solaris 10 that do not require a separate kernel. They provide additional high-security labeling features to meet regulatory and compliance requirements.

Solaris 10 with Trusted Extensions is currently in evaluation for the Common Criteria Certification Labeled Security Protection Profile (LSPP) at Evaluation Assurance Level 4+ (EAL 4+).

The updated also includes the "secure by default" feature, which first appeared in an OpenSolaris build earlier this year. With secure by default, most external-facing services are turned off at the point of initial installation. Only services required to login and boot the OS are enabled by default.

"The whole thing is about making Solaris install in a mode that is secure out of the box," OpenSolaris developer Martin Englund wrote in a blog posting earlier this year. "This should be a no brainer, but since Solaris always strive to be backward compatible it is not easy doing a change like this."

Solaris 10 was originally released in 2004 and was last updated in June. Update 2 included the new ZettaByte File System (ZFS), as well as optimizations in the network stack around SSL and UDP performance.

Sun Solaris data recovery, sun solaris file recovery, sun solaris volume recovery

Adding a New Hard Disk system in UNIX, LINUX

2006-12-16T13:40:00.000-08:00

Adding a New Hard Disk system, the following
Posted by sales under redhat

Running fsck This is because on a running system, usually a significant part of the file system is always being worked upon in memory. In fact, if possible, it is a good idea to run the sync command before shutting down the machine, as this will flush unwritten file system blocks in memory to the disk - and hence avoid boot time file system inconsistencies. As you’ll recall from Chapter 1, during the Red Hat Linux 9 installation we are prompted to create a boot disk. It is always a good idea to create a boot disk. This is particularly useful if the partition containing the bootable image of the kernel becomes corrupted. With a boot disk it is possible to boot up to a minimal shell and run diagnostics and repair tools. If you have important data on your system, it is always a good idea to use some form of backup utility to back up the system periodically. We look at this in more detail in Chapter 10. Running fsck Most Unix file system partitions contain a super block, which is essentially a ‘book-keeping section’ of that partition . When a system is shut down gracefully (that is, without errors), a flag is set to indicate the graceful shutdown. When the system comes up the next time, it examines this flag to see if the shutdown was graceful or not. If not, the system may require us to run diagnostic and repair tools on that partition. The most popular diagnostics and repair utility on Linux (and in the UNIX world) is fsck. Running fsck with the y option allows fsck to proceed with any repairs that need to be performed in the course of diagnostic analysis. The N option to fsck would perform a dry run, i.e. the actual repair routines would not be performed but only printed out. Here is a typical output with the N option on a partition with a corrupted superblock. $ /sbin/fsck -N /dev/hda fsck 1.27 (8-Mar-2002) [/sbin/fsck.ext3 (1) — /dev/had] fsck.ext3 /dev/hda $ /sbin/fsck -y /dev/hda fsck 1.27 (8-Mar-2002) e2fsck 1.27 (8-Mar-2002) Couldn’t find ext3 superblock, trying backup blocks… fsck.ext3: Bad magic number in super-block while trying to open /dev/hda The superblock could not be read or does not describe a correct ext3 file system. If the device is valid and it really contains an ext3 file system (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 Tuning the File System The tune2fs command allows us to set various tunable parameters on the ext2 file system partitions. It is commonly used to control the frequency at which fsck is automatically run on a file system: The fsck utility could be run once every few days, weeks, or months by specifying the -i option. For example, the following command would force an execution of fsck once every two weeks: $ tune2fs -i 2w The -c option controls the running of fsck based on the number of reboots. For example, -c10 indicates that the fsck will be run once in every 10 system reboots 225

Note: If you are looking for reliable and quality webspace company to host and run your servlet application check professional servlet hosting services

Redhat data recovery, recovery from red hat operating system, volume recovery from HFS file system, Redhat data recovery, recovery from red hat operating system, volume recovery from HFS file system, the following
Posted by sales under redhat

Running fsck This is because on a running system, usually a significant part of the file system is always being worked upon in memory. In fact, if possible, it is a good idea to run the sync command before shutting down the machine, as this will flush unwritten file system blocks in memory to the disk - and hence avoid boot time file system inconsistencies. As you’ll recall from Chapter 1, during the Red Hat Linux 9 installation we are prompted to create a boot disk. It is always a good idea to create a boot disk. This is particularly useful if the partition containing the bootable image of the kernel becomes corrupted. With a boot disk it is possible to boot up to a minimal shell and run diagnostics and repair tools. If you have important data on your system, it is always a good idea to use some form of backup utility to back up the system periodically. We look at this in more detail in Chapter 10. Running fsck Most Unix file system partitions contain a super block, which is essentially a ‘book-keeping section’ of that partition . When a system is shut down gracefully (that is, without errors), a flag is set to indicate the graceful shutdown. When the system comes up the next time, it examines this flag to see if the shutdown was graceful or not. If not, the system may require us to run diagnostic and repair tools on that partition. The most popular diagnostics and repair utility on Linux (and in the UNIX world) is fsck. Running fsck with the y option allows fsck to proceed with any repairs that need to be performed in the course of diagnostic analysis. The N option to fsck would perform a dry run, i.e. the actual repair routines would not be performed but only printed out. Here is a typical output with the N option on a partition with a corrupted superblock. $ /sbin/fsck -N /dev/hda fsck 1.27 (8-Mar-2002) [/sbin/fsck.ext3 (1) — /dev/had] fsck.ext3 /dev/hda $ /sbin/fsck -y /dev/hda fsck 1.27 (8-Mar-2002) e2fsck 1.27 (8-Mar-2002) Couldn’t find ext3 superblock, trying backup blocks… fsck.ext3: Bad magic number in super-block while trying to open /dev/hda The superblock could not be read or does not describe a correct ext3 file system. If the device is valid and it really contains an ext3 file system (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 Tuning the File System The tune2fs command allows us to set various tunable parameters on the ext2 file system partitions. It is commonly used to control the frequency at which fsck is automatically run on a file system: The fsck utility could be run once every few days, weeks, or months by specifying the -i option. For example, the following command would force an execution of fsck once every two weeks: $ tune2fs -i 2w The -c option controls the running of fsck based on the number of reboots. For example, -c10 indicates that the fsck will be run once in every 10 system reboots 225

Note: If you are looking for reliable and quality webspace company to host and run your servlet application check professional servlet hosting services

Redhat data recovery, recovery from red hat operating system, volume recovery from HFS file system, Redhat data recovery, recovery from red hat operating system, volume recovery from HFS file system

Building Unix FIle Systems for AFS or NFSv4

2006-12-16T13:28:00.000-08:00

Building filesystem servers in user-land for protocols like AFS or NFSv4

A friend of mine who dabbles (to put it lightly) on AFS was telling me this weekend about a problem he'd had to contend with.

AFS, like NFSv4, can multiplex multiple users on the client side onto one connection, but unlike NFS servers, AFS servers [OpenAFS] are typically built to run in user-land. Because of this and because of differences in filesystem semantics between POSIX (which NFS approximates) and AFS, AFS servers typically implement not only the server but the whole filesystem in user-land, completely avoiding the underlying OS' own filesystems.

So one cannot normally share non-AFS filesystems with AFS, and one cannot use AFS filesystems except through the AFS protocol. But my friend Jeff Hutzelman needed to do just that, so he built a prototype to demonstrate that it was possible.

This reminded me of what used to be a pet project of mine for Solaris that has not panned out. There is a class of applications for which a feature of Windows and some other other OSes, per-thread credentials, can be very useful. Namely, multi-threaded server applications running in user-land that need to perform certain operations as though they were performed by a client user process, not the server process. File servers like OpenAFS are a good example of this. Now, OpenAFS doesn't actually need such a feature: its filesystem is implemented in user-land as well, so there's no need for the kernel to provide the server with such a facility.

Well, my team had what I thought was a use case for this facility in Solaris, and so I tried to get a project going to add per-thread credentials support to Solaris. Long story short: there are too many little and big semantics and backwards compatibility problems to resolve, so we had to find an alternative solution. Of course, alternatives existed, and we settled for one: fork() separate worker processes, one per-client user, from a privileged one, adopt the credentials of the client users in the child processes, and run the operations in question in the worker processes.

Now, I'm blogging this a) because I think the problems we ran into when with per-thread credentials are interesting, b) to explore the alternatives and design patterns.

I may blog about (a) in-depth in the future. For now suffice it to say that the problems range from "what credentials will signal handlers, shared object .init sections, etc... run with?" to "what happens if a library, unbeknownst to the application, creates threads from a thread running with different credentials than the process itself, but the library also doesn't know about per-thread credentials?"

Some of these have relatively simple answers, others cannot be resolved with ease or at all. When you mix multiple security contexts in one VM address space you have to be very careful. In particular you have to make sure that every component of the environment knows about this and follows agreed upon protocols. Multi-user OS kernels like Solaris and Linux are examples of programs that work like that (but then, they're not user-land programs).

But the world of multi-threaded Unix user-land has always assumed a single credential used by all threads in the same process (setuid(2) affects all threads in the caller's process, though it does not impact in-progress system calls), and violating this assumption could cause lots of security bugs when using code written when that assumption was valid; the system is too open and too large to make it safe to violate this assumption (except for the simplest of programs). As the enormity of the problem of making this safe for the use case that we had in mind sank in we simply had to settle for more orthodox alternatives.

As for (b), I've written a small prototype of a library that implements: a worker process abstraction and variants of system calls that take an argument specifying a user to run the system call as (actually, the prototype does this only for open(2): doas_open()).

Additionally, for the fun of it and to explore some of the problems in (a), I have an LD_PRELOADable shared object that implements an illusion of per-thread credentials.

This sort of facility (e.g., doas_open()) could be very useful in building multi-threaded fileservers for protocols like AFS and NFSv4, running in user-land but sharing filesystems implemented by the OS, rather than filesystems implemented in the same user-land program: such programs need to be able to run system calls like open(2) with the credentials that correspond to the clients on behalf of which the server calls open(2). This prototype provides just that, albeit using fork()ed worker processes under the hood (but the IPC mechanism used is doors, which is very fast). (Note that I/O system calls like read(2), write(2), getmsg(2), putmsg(2), recvmsg(2), pread(2), pwrite(2), and so on don't need to be proxied through worker processes: what matters is the credential used to create the file descriptor in question, not the credentials of the caller these I/O calls.)

One of the limitations of my friend's prototype AFS server is that it can't perform local filesystem operations as the clients. Perhaps my prototype can help.

The library consists of two main functions:

* doas_alloc(), which returns a handle to a worker process and takes a description of the user's credentials as an argument
* doas_free(), which releases handles create by doas_alloc()

and then doas_open(), which is just like open(2), but augmented with a worker process handle argument.

Actually, the handle represents a user credential, not a worker process -- that a worker process is used is an implementation detail.

The interface for the per-thread credential emulator (which requires interposing on open(2) and friends) consists of a single additional function: doas() which takes a handle and a callback function and data arguments -- calls to open(2) and friends in the callback function and all functions it calls in the same thread will be changed to calls to doas_open() with the handle passed to doas().

So there you have it. A framework for building function wrappers that take as an additional argument a "user impersonation token" (to borrow from Windows terminology), portable to any Unix that has IPC methods that allow for file descriptor passing. And a framework for emulating per-thread credentials, written with zero extensions to the underlying OS, portable to any Unix whose linker/run-time linker supports interposition.

The API looks like this:

int doas_open(int idx, char *fname, int oflag, mode_t mode);

/* get current doas subject index */
int doas_current(void);

/*
* get a new subject index for a new subject represented by the setup proc and
* setup_data (which are called to setup a worker process' environment)
*/
int doas_idx_new(int (*setup_proc)(void *), void *setup_data);

/* release a subject index */
void doas_done(int idx);

/*
* arrange for interposers called by this same thread to proxy syscalls to the
* worker process associated with the given subject index
*/
int doas(int idx, int (*doas_func)(void *), void *doas_data);

It could be improved somewhat. For example, the handles shouldn't be int but int64_t, and the library should make sure no handles are reused in the same process so it can detect dangling references to dead handles.

The code for forking worker processes is interesting to me because it might be a re-usable design. The parent process creates a door, forks a child and then the child creates its door and sends it to the parent via a door call on the parent's door. That may seem like a complicated dance, but it isn't really, and I believe that the asymmetry that leads to is is central to the doors IPC story.

The door server forker consists of:

* A rendez-vous point -- the function that fork()s the child has to wait for the child to call the parent's door; the parent's door server function will run in a separate thread, so a simple condition variable will do
* A door server function in the parent
* A function to setup the rendez-vous, start the parent door server, fork() the child and wait for it, create the child's door, pass it back to the parent and enter door_return(3DOOR)
* Setting the child worker process' credentials is done through a callback in this prototype, but it could be done with an octet string token description of the credentials to us

The rendez-vous and the function that forks the workers look like this (pardon the printf()s):

struct doas_fork_rendez_vous {
pthread_cond_t cv;
pthread_mutex_t lock;
int idx;
int dfd;
int this_dfd;
};

static
int
fork_doas_door(int idx, int (*setup_proc)(void *), void *setup_data)
{
pid_t pid;
int dfd;
struct doas_fork_rendez_vous rv;

if (idx >= ndoors)
return (-1);

if (pthread_cond_init(&rv.cv, NULL) != 0)
return (-1);

if (pthread_mutex_init(&rv.lock, NULL) != 0) {
(void) pthread_cond_destroy(&rv.cv);
(void) pthread_mutex_destroy(&rv.lock);
return (-1);
}

(void) pthread_mutex_lock(&rv.lock);

rv.idx = idx;
rv.dfd = -1;

dfd = door_create(doas_fork_parent, (void *)&rv, DOOR_UNREF);

rv.this_dfd = dfd;

if (dfd < 0) {
(void) pthread_cond_destroy(&rv.cv);
(void) pthread_mutex_destroy(&rv.lock);
return (-1);
}

if ((pid = fork()) < 0) {
(void) pthread_cond_destroy(&rv.cv);
(void) pthread_mutex_destroy(&rv.lock);
(void) door_revoke(dfd);
return (-1);
}

if (pid == 0) {
int dfd2 = -1;
int failed = 0;
door_arg_t darg;
door_desc_t dd;

(void) memset(&darg, 0, sizeof (darg));

darg.data_ptr = NULL;
darg.data_size = 0;

/* child */

dfd2 = door_create(doas_proc, NULL, DOOR_UNREF);

/*
* If setup_proc == NULL we're setting up a worker
* process with the same characteristics as the parent,
* e.g., so the parent can drop privileges but retain
* a door to this privileged worker process.
*/
if (setup_proc != NULL && setup_proc(setup_data) < 0) {
/* failure */
failed = 1;
} else {
dd.d_attributes = DOOR_DESCRIPTOR;
dd.d_data.d_desc.d_descriptor = dfd2;
darg.desc_ptr = ⅆ
darg.desc_num = 1;
}

if (door_call(dfd, &darg) < 0) {
(void) door_revoke(dfd2);
exit(1);
}

if (failed) {
(void) door_revoke(dfd2);
exit(1);
}

/* XXX should rv.cv/rv.lock be cleaned up in the child?? */

/* Service the door */
(void) door_return(NULL, 0, NULL, 0);
exit(1); /* shouldn't happen */
/* NOTREACHED; */
}

/* parent -- wait for child to pass back its door */
printf("Parent is going to sleep on cv\n");
(void) pthread_cond_wait(&rv.cv, &rv.lock);
printf("Parent is back from sleeping on cv\n");

/* we no longer need the door over which the child passed its door */
(void) door_revoke(dfd);

/* cleanup */
(void) pthread_mutex_unlock(&rv.lock);
(void) pthread_cond_destroy(&rv.cv);
(void) pthread_mutex_destroy(&rv.lock);

/* save the child's door */
return (doors[idx] = rv.dfd);
}

The door server function in the parent looks like this:

/* ARGSUSED */
static
void
doas_fork_parent(void *cookie, char *argp, size_t arg_size,
door_desc_t *dp, uint_t n_desc)
{
struct doas_fork_rendez_vous *rv;

rv = (struct doas_fork_rendez_vous *)cookie;

if (arg_size == 0 && argp == DOOR_UNREF_DATA) {
printf("doas_fork_parent() unref\n");
door_revoke(rv->this_dfd);
door_return(NULL, 0, NULL, 0);
}

if (n_desc == 1)
rv->dfd = dp->d_data.d_desc.d_descriptor;

/* wake up the parent */
printf("doas_fork_parent() here!\n");
(void) pthread_mutex_lock(&rv->lock);
(void) pthread_cond_broadcast(&rv->cv);
(void) pthread_mutex_unlock(&rv->lock);
printf("doas_fork_parent() cond_broadcast done...!\n");

(void) door_return(NULL, 0, NULL, 0);

return;
}