Ein Kraut im Käseland

Well, I can imagine three common scenarios spontaneously:

1) The files system is really full. No further comments on this one

2) The file system ran out of inodes. Oh, this can be a fun one, because the Solaris 'df' does not seem to support the common 'df -i' argument. Well, it actually does it with a trick. Try the following:


---
$> df -F ufs -o i
---


As a result, you will get a list of the amount of used and free inodes for each filesystem, plus a percentage. If you hit 100% on a filesystem, it will most likely a NAS filer or something like this, and such an incident is usually a ticket for a real fun ride. There are only two ways to increase the number of inodes and both are most likely not a job for an operator on a night shift:

- backing up the filesystem, and doinga newfs with an increased inode number
- switching to ZFS (ZFS doesn't use inodes, it replaced them with a dynamically allocated znode structure)

In my experience, this is a pretty common problem, at least more common than the next one.


3) The file system is locked by a process. In Linux, you would usually use the 'lsof' command to resolve this. Bad news: lsof under solaris 10 is broken, don't even think about downloading a Sunfreeware package - I'll call an exorcist if you do this - or even trying to compile it. Instead, use the 'pfiles' command to loop over the process list.


---
#!/bin/bash

for i in `ps -o pid`
do
pfiles $i >> /tmp/open_files
echo "Current working directory:" >> /tmp/open_files
pwdx $i >> /tmp/open_files
done
less /tmp/open_files
---


In this file, there will be a list of all open files, ports, sockets, etc. plus the $PWD of each process will be listed. This list will be quite long, so just search for the path of the file system's mountpoint.

Posted by Ralf Ramge

#!/bin/bash
for dev in `awk -F'"' '/sd/ {print $2}' /etc/path_to_inst`
do
prtconf -v /devices/$dev|egrep -i "id1|dev.dsk.*s2"
done


SATA

On X4500 servers, and probably on SATA devices in general (untested), the script will generate a list:



value='id1,sd@SATA_____HITACHI_HDS7250S______KRVN67ZBHULG0H'
dev_link=/dev/dsk/c0t0d0s2



SAS and FibreChannel

On external SAS and FC storages, you get the IDL / WWN instead.


value='id1,sd@n5000c5000904842b'
dev_link=/dev/dsk/c8t18d0s2


That usually doesn't help. Instead, use `iostat -En` to map the device (without the slice number!) to the corresponding serial. Example:


c8t18d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: SEAGATE Product: ST373455SSUN72G Revision: 0892 Serial No: 0812R2QQFA
Size: 73.41GB <73407865344 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

Posted by Ralf Ramge

I just received the news that it's now possible to use ZFS for serious random I/O based applications and not just for lower I/O loads or streaming services - the JBODs are now supported in cluster and I/O multipathing environments. The statement was originally scheduled for yesterday, but I'm still happy to see that it arrived today. Kinda saves my current project


=======================================================================
Recently Completed Solaris Cluster Configurations
=======================================================================
- Support for Sun Storage J4200 and J4400 arrays (SAS HDD only)
with SAS Multipathing (aka Alamo and RiverWalk)
---------------------------------------------------------------
Details of support are as follows:

Supported version of Solaris: Solaris 10 5/08 + patches
Supported Solaris Cluster Release: SC 3.1, SC 3.2 and later + patches

Supported Topologies:
Must be connected to exactly two cluster nodes
(N + 1, Clustered Pairs and Pair + N )

Supported Hosts:

SPARC: M4000, M5000, M9000,
T1000, T2000, T5120, T5220, T5140, T5240,
V215 , V245, V445

x64: Sun Fire X2100 M2, X2200 M2 , X4100 M2, X4200 M2,
X4140, X4150, X4440, X4450, X4600, X4600 M2

Supported HBA: SG-XPCIE8SAS-E-Z

Posted by Ralf Ramge

An example should be pretty self-explaining:


---
root@crmfarm01a:~> ramdiskadm -a ramdisk1 1g
/dev/ramdisk/ramdisk1
root@crmfarm01a:~> ramdiskadm -a ramdisk2 1g
/dev/ramdisk/ramdisk2
root@crmfarm01a:~>
root@crmfarm01a:~>
root@crmfarm01a:~>
root@crmfarm01a:~> zpool create ramdisk mirror /dev/ramdisk/ramdisk1 /dev/ramdisk/ramdisk2
root@crmfarm01a:~>
root@crmfarm01a:~> zpool status ramdisk
Pool: ramdisk
Status: ONLINE
scrub: Keine erforderlich
config:

NAME STATE READ WRITE CKSUM
ramdisk ONLINE 0 0 0
mirror ONLINE 0 0 0
/dev/ramdisk/ramdisk1 ONLINE 0 0 0
/dev/ramdisk/ramdisk2 ONLINE 0 0 0

Fehler: Keine bekannten Datenfehler
root@crmfarm01a:~> zfs list ramdisk
NAME USED AVAIL REFER MOUNTPOINT
ramdisk 86K 984M 24.5K /ramdisk
root@crmfarm01a:~> reboot
[...]
syncing file systems... done
WARNING: CMM: Node being shut down.
rebooting...
Resetting...

SPARC Enterprise T5220, No Keyboard
Copyright 2007 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.27.10, 32640 MB memory available, Serial #82542296.
Ethernet address 0:14:4f:eb:7e:d8, Host ID: 84eb7ed8.



Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@0,0:a File and args:
SunOS Release 5.10 Version Generic_137111-03 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hostname: crmfarm01a
[...]
Last login: Thu Sep 25 14:07:45 2008 from solrara.webde.l
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
# bash
root@crmfarm01a:~> zpool status ramdisk
Pool: ramdisk
Status: UNAVAIL
Zustand: Mindestens ein Gerät konnte nicht geöffnet werden. Es sind nicht genügend
Replikationen für den weiteren Betrieb des Pools vorhanden.
Aktion: Fügen Sie das fehlende Gerät an und setzen Sie es mit 'zpool online' in Betrieb.
Siehe: http://www.sun.com/msg/ZFS-8000-D3
scrub: Keine erforderlich
config:

NAME STATE READ WRITE CKSUM
ramdisk UNAVAIL 0 0 0 Nicht genügend Replikationen
mirror UNAVAIL 0 0 0 Nicht genügend Replikationen
/dev/ramdisk/ramdisk1 UNAVAIL 0 0 0 Öffnen nicht möglich
/dev/ramdisk/ramdisk2 UNAVAIL 0 0 0 Öffnen nicht möglich
root@crmfarm01a:~>
---


As you can see, ramdisks do not survive reboots, so think twice before using them for ZFS instead of sparse files.

Deleting a ramdisk manually would have been done by issuing ramdisk -d ramdisk1.

Posted by Ralf Ramge

A customer wanted to replace a RAIDZ consisting of 3x 1 TB drives with 5x 1 TB drives, of which only 2 drives are new, but he wanted to preserve the data by creating the final RAIDZ with 4 drives only and copying the data to the 5th. This means that the final zpool needs to be created with 4 drives instead of 5, and the 5th drive needs to be added later, after the preserved data got copied to the new RAIDZ. since it's not possible to add any more device to a RAIDZ or a mirror without creating an unwanted stripe, you have to work with a temporary file.


1. Create a sparse file on an existing filesystem. The size should be
the same as your disks.
2. Create the raidz with 4 of the drives and the sparse file.
3. Export the zpool.
4. Delete the sparse file
5. Import the zpool. It should come up as degraded, since one of its
vdevs is missing.
6. Copy your files onto the zpool.
7. replace the file vdev with the 5th disk.


Thanks to Brandon High for the tip, I quoted him here. You can make it a bit faster by offlining the sparse file (zpool offline) at step 3 and skipping steps 4 and 5 after this.

Posted by Ralf Ramge

Last week, Jim Zenlin - that's the Linux lobbyist who once lost his self-declared "Linux is an open war with microsoft" campaign and now tries to make people forget that he instead became recipient of Microsoft''s development aid - badly needed some publicity and caused a stir after he noticed that there's another serious player on the free software market. One of the big design flaws of his speech has been his denial of the relevance of technologies like DTrace and ZFS, and a few sentences later he talked about copying them to allow Linux to make the gap to Solaris' merits smaller.

Ben Rockwood wrote an article which wasn't less polemic than Zenlin's ridiculous rant, but at least it's funny. And it contains my personal quote of the week.


[...]
"Given Sun's own Linux support on its Sparc and x86 servers, Zemlin suggests that it should make ZFS and DTrace available under a Linux-compatible license."

And there it is... Linux advocates bash Sun & Solaris right, left and center, but after it all they just want to rape the OS. Not share, not collaborate... rape. I have never been an advocate of GPLv2 release of the code for this explicit reason. Its like a bad date, she smiles and winks a little, calls you names but takes you home anyway, and in the morning your wallet is gone.
[...]



Anyway, I found Zenlin's rant rather amusing. People, comapnies and lobbies usually react this way when they are disturbed in their selfishness and can't keep up with their competition when it comes to inventions, market shares and public reaction. Otherwise they would just ignore the competitors, like Zenlin still ignores HP-UX or AIX. Remember Microsoft and their penguin poster? I think Zenlin sees himself in the same position now.

But in the end that stuff doesn't matter to me. If there's something I hate, it's UNIX wars. Too bad that there are still people out there who try to earn money by starting them. Luckily, those people are not Sun employees. I prefer organziations (and people) who persuade customers with results over those who just talk about it. My life and the future of my family depend on it. And, as long as I can continue to save a customer's business critical projects month after month, myself, my employer, and our customers are on the right path.

Posted by Ralf Ramge

During our final chapter, we're going to use RBAC together with the SMF. But first, we need a running service. Let's try Apache 2:


---
root@solcluster03:~> cd /etc/apache2/
root@solcluster03:/etc/apache2> cp httpd.conf-example httpd.conf
root@solcluster03:/etc/apache2> svcadm enable apache2
root@solcluster03:/etc/apache2> svcs apache2
STATE STIME FMRI
online 17:04:44 svc:/network/http:apache2
root@solcluster03:/etc/apache2>
---


Okay, the web server is configured and online.

Step 1: Examining the authorization attribute database

As a first step, you should always check if there's already a suitable entry in the /etc/security/auth_attr database. Like prof_attr describes profiles and user_attr contains a list of users, auth_attr is a database for required authorizations. Applications check against this database by default and nsswitch.conf refers to it:


---
rara@solrara:/etc/security> grep auth_attr /etc/nsswitch.conf
auth_attr: files
rara@solrara:/etc/security>
---


Now, let's see how such authorizations are handled:


---
rara@solrara:/etc/security> grep manage /etc/security/auth_attr | tail -10
solaris.smf.manage.name-service-cache:::Manage Name Service Cache Daemon Service States::help=SmfNscdStates.html
solaris.smf.manage.power:::Manage Power Management Service States::help=SmfPowerStates.html
solaris.smf.manage.routing:::Manage Routing Service States::help=SmfRoutingStates.html
solaris.smf.manage.rpc.bind:::Manage RPC Program number mapper::help=SmfRPCBind.html
solaris.smf.manage.sendmail:::Manage Sendmail Service States::help=SmfSendmailStates.html
solaris.smf.manage.ssh:::Manage Secure Shell Service States::help=SmfSshStates.html
solaris.smf.manage.system-log:::Manage Syslog Service States::help=SmfSyslogStates.html
solaris.smf.manage.tnctl:::Manage Refresh of Trusted Network Parameters::help=TNctl.html
solaris.smf.manage.tnd:::Manage Trusted Network Daemon::help=TNDaemon.html
solaris.smf.manage.x11:::Manage X11 Service States::
rara@solrara:/etc/security>
---


As you can see, common services have an entry here which consists of a profile name and comments. Apache 2 is not listed, so we have to append a corresponding entry to the database:


---
root@solcluster03:/etc/apache2> echo "solaris.smf.manage.apache2:::Manage the apache 2 web service::" >> /etc/security/auth_attr
root@solcluster03:/etc/apache2>
---


Step 2: Linking a user and a service to the authorization entry

Let's have a look at the service properties:


---
root@solcluster03:/etc/apache2> svcprop -p general apache2
general/enabled boolean false
general/entity_stability astring Evolving
root@solcluster03:/etc/apache2>
---


That's not much. What we need is a property called general/action_authorization.

general/action_authorization allows an user to restart a service. By doing so, the current state of the service is not changed.

Since this property doesn't exist, we'll have to create it.


---
root@solcluster03:/etc/apache2> svccfg -s apache2 setprop general/action_authorization= astring: 'solaris.smf.manage.apache2'
---


The astring content is the name of the entry we just added to the auth_attr file.

To activate the new pproperty, we need to refresh the service. This way, the service manifest will be read again.


---
root@solcluster03:/etc/apache2> svcadm refresh apache2
root@solcluster03:/etc/apache2> svcprop -p general apache2
general/enabled boolean true
general/action_authorization astring solaris.smf.manage.apache2
general/entity_stability astring Evolving
root@solcluster03:/etc/apache2>
---


Okay. The service is RBAC-aware now. Linking the user "rara" to the RBAC authorization is all what's left to do. This is done with usermod, too. But this time, we use the -A (Authorization) parameter instead of -P (Profile).


---
root@solcluster03:/etc/apache2> usermod -A 'solaris.smf.manage.apache2' rara
UX: usermod: rara is currently logged in, some changes may not take effect until next login.
root@solcluster03:/etc/apache2>
---


Logout, login, done. Have fun.

But what do you have to do in case you want to allow the user to enable and disable the service, too? Instead of allowing him to restart the service only?
That's basically the same procedure. All you have to do is adding a second property.

The service property general/value_authorization allows enabling and disabling a service. By doing so, the current state of a service is changed.


---
root@solcluster03:/etc/apache2> svccfg -s apache2 setprop general/value_authorization= astring: 'solaris.smf.manage.apache2'
root@solcluster03:/etc/apache2> svcadm refresh apache2
root@solcluster03:/etc/apache2>
---


That's all.

Okay, now you learned the basics of RBAC administration. I hope you noticed how easy it is. Create a profile or use a given one, create a role, link users against it, done. Now all what's left to do is kicking sudo from the hard drives

In our next tutorials, we'll focus on an important topic which is kind of a mystery to most Solaris administrators, but sooner or later everyone will have to face it: Building fail-over clusters using Solaris Cluster 3.2 Update 1 or newer.

Posted by Ralf Ramge

Amateurs.

Posted by Ralf Ramge

Neelakanth Nadgir wrote a very useful script when it comes to ZFS analysis. His arcstat script monitors the ARC.

Example:


---
root@herpes:~> ./arcstat.pl
Time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
08:55:27 1G 156M 9 68M 4 87M 50 10M 6 4G 4G
08:55:28 190 128 67 126 67 2 100 1 3 4G 4G
08:55:29 280 154 55 143 53 11 100 0 0 4G 4G
08:55:30 225 140 62 140 62 0 0 0 0 4G 4G
08:55:31 310 134 43 134 43 0 0 0 0 4G 4G
08:55:32 300 128 42 126 42 2 100 0 0 4G 4G
^C
root@herpes:~>
---


Supported parameters:


---
root@herpes:~> ./arcstat.pl --help
Arcstat version 0.1
Usage: arcstat.pl [-hvx] [-f fields] [-o file] [interval [count]]
-x : Print extended stats
-f : Specify specific fields to print (see -v)
-o : Print stats to file
-s : Specify a seperator

Examples:
arcstat -o /tmp/a.log 2 10
arcstat -s , -o /tmp/a.log 2 10
arcstat -v
arcstat -f Time,Hit%,dh%,ph%,mh%
root@herpes:~>
---


I offer a copy of it here, just in case Neelakanth's page at blogs.sun.com is not available forever: arcstat.pl.gz

Posted by Ralf Ramge

Hi,

as you probably know, ZFS uses the main system RAM as an ARC cache. The maximum size of this cache is the total size of physical RAM - 1 GB . Well, this is a maximum size only. If you want to find out how much RAM is allocated right now, there are two ways to find it out.

1. kstat


---
root@herpes:~> kstat -m zfs | grep size
size 4643030016
root@herpes:~>
---


In this example, the size of the ZFS cache is rougly 4.6 GB.

2. mdb

If you want a more detailed summary, you can ask mdb.


---
root@herpes:~> echo ::kmastat | mdb -k | head -3 && echo ::kmastat | mdb -k | grep zio
cache buf buf buf memory alloc alloc
name size in use total in use succeed fail
------------------------- ------ ------ ------ --------- --------- -----
mdb: write to stdout failed, exiting
zio_buf_512 512 1416 2744 1404928 245884225 0
zio_data_buf_512 512 0 8 4096 279239 0
zio_buf_1024 1024 6 216 221184 111482844 0
zio_data_buf_1024 1024 0 0 0 0 0
zio_buf_1536 1536 0 152 233472 27044716 0
zio_data_buf_1536 1536 0 0 0 0 0
zio_buf_2048 2048 0 146 299008 115695316 0
zio_data_buf_2048 2048 0 18 36864 283593 0
[...]
zio_buf_131072 131072 2 23 3014656 38167060 0
zio_data_buf_131072 131072 35260 35260 326631424 614130737 0
Total [zio_buf] 337920000 617752615 0
zio 4633149440 17070817280 0 47945988 0
zio_buf 4633149440 4633149440 4633149440 47945988 0
root@herpes:~>
---

Posted by Ralf Ramge

Let's give the user "rara" the right to use the snoop command.

Step 1: Creating the role

First, let us check if there's already a role defined:


---
root@solcluster04:~> roles
No roles
root@solcluster04:~>
---


Nope, so let's create a role. The handling of roles is quite similar to regular UNIX accounts and pretty easy to understand. Just have a look at this:


---
root@solcluster04:~> roleadd -m -d /export/roles/snoopy snoopy
64 blocks
root@solcluster04:~> passwd snoopy
New Password:
Re-enter new Password:
passwd: password successfully changed for snoopy
root@solcluster04:~>
---


As you can see, we added the role using the roleadd command and assigned a password with passwd.

Next, we need to tell Solaris that "rara" should be able to assume this role. We use usermod for this, since we me modify a user profile here.


---
root@solcluster04:~> usermod -R snoopy rara
UX: usermod: rara is currently logged in, some changes may not take effect until next login.
root@solcluster04:~>
---


Unlike common user data, this is not stored in /etc/passwd, but in /etc/user_attr instead. Give it a try:


---
root@solcluster04:~> grep rara /etc/user_attr
rara::::type=normal;roles=snoopy;profiles=ZFS File System Management
root@solcluster04:~>
---


The ZFS File System Management entry is a leftover from chapter II, just ignore it. The important part of the entry is roles=snoopy. Please take note that the path of the user attribute database is /etc/user_attr, and not /etc/security/user_attr.

Okay, now we have the role, but we have not defined what the user is allowed to do with it.

Step 2: Creating the profile

First, we create a simple profile. Profiles are stored in the profile attribute database, /etc/security/prof_attr


---
root@solcluster04:~> echo "Snooper:::Snoop user role:" > /etc/security/prof_attr
---


This line defines a profile called "Snooper". It has "Snoop user role" as a comment. Don't forget the ":" at the end of the line, that's important.

Good. So far we have create a role and a profile. Let's tie these two together.


---
root@solcluster04:~> rolemod -P Snooper snoopy
root@solcluster04:~>
---


Okay, done. The /etc/user_attr file will now reflect this change. Let's have a look at it.


---
root@solcluster04:~> grep snoopy /etc/user_attr
rara::::type=normal;roles=snoopy;profiles=ZFS File System Management,Primary Administrator
snoopy::::type=role;profiles=Snooper
root@solcluster04:~>
---


Step 3: Linking the profile to the snoop command

There's one more step needed, because our role has still no idea what all that fuzz is about. Let's link it to the snoop command now.


---
root@solcluster04:~> echo"Snooper:suser:cmd:::/usr/sbin/snoop:uid=0" > /etc/security/exec_attr
root@solcluster04:~>
---


As you can see, this entry contains three important fields.

First comes Snooper, the profile name, which is needed for linking the profile and the snoop command together.

Second, /usr/sbin/snoop is the path to the snoop binary. If you want to give a role access to more commands than just one, you create a single line for each of the commands. Since every line has the "Snooper" identifier, this won't create a problem. Multiple lines are a common practice.

Third, uid=0 defines the uid under which the command will be executed, in our case it's the root uid.

Ignore the other fields for now. Read the man page after you became familiar with what we did now; RBAC is one of the Solaris topics which is very easy and straight forward, but if you look into the official documentation, you'll get the impression that you need to obtain a mountain of knowledge first. Concentrate on the important stuff instead, you can still learn the rest later.

Step 4: Using the role

Okay, let's give it a try. Log in as the user "rara" and then assume the role by using the su command. If it works, you tell "rara" the snoopy password and you can be 100% sure that "rara" is able to snoop the network - and nothing else.


rara@solcluster04:~> /usr/sbin/snoop
snoop: /dev/bge0: Permission denied


See? "rara" cannot use the "snoop" command by default. He has to assume the role first, because only the role is allowed to do this. That's way better than using pfexec, because you did not destroy your last security barrier.


---
rara@solcluster04:~> su snoopy
Password:
---



"rara" assumed the role now. Let's give it a try.


---
$ /usr/sbin/snoop
Using device /dev/bge0 (promiscuous mode)
solcluster04 -> solrara.webde.local TCP D=56773 S=22 Push Ack=153967203 Seq=1239235026 Len=64 Win=49640
solrara.webde.local -> solcluster04 TCP D=22 S=56773 Ack=1239235026 Seq=153967203 Len=0 Win=49640
[...]
---


Congratulations Feel free to have a look at /var/adm/sulog now. Assuming the role by "rara" is logged. That's another difference to pfexec.


In the next chapter, which will also be the last, we'll learn how to link roles to the SMF. For instance, this enables us to give "rara" the right to restart a service, but not to disable it. You want to know how this works in case your company has operators or developers with the urge to restart their stuff from time to time, but who are not educated enough to be granted full root privileges.

Posted by Ralf Ramge

I promised to tell you why pfexec is evil. We'll, that's pretty simple. There's a reason why certain commands of the "root world" are separated from the "user land". The magic word is security. As root, you are responsible for the things your server does. If one of your users does a mistake, may it be deliberately or by accident, you're the person who has to answer the question why the user had been able to do this.

Maintaining basic system security also means securing your own job.

The sudo command, for instance, makes life for the users more convenient. And some administrator really believe that it secures a system because a user can get root privileges without the need of knowing the root password. But in reality, you sacrifice a lot of your security. Regular users are not trustworthy. If they were, giving the users the root password or uid 0 wouldn't be a problem, right?
But what bad administrators don't see is that they remove the last line of defense. Untrustworthy users usually choose bad passwords. And they use the same password over and over again. As an administrator, you expect the root password to be secret (otherwise the user would have it). But the user doesn't.

Too bad an attacker only needs the user password to log in to the user's account, and needs the same password only to get root privileges.

Also, users are well-known for taking a break without locking their screens. Too bad that sudo only asks for the password at certain intervals and not every time. So the mere possibilty of a non-locked screen is enough to turn your security policy pretty useless.

And did I mention that nearly every installation (and most administrators) I saw until now allows users to get root shells by typing sudo su -, just because doing it better would be "inconvenient" for a person? check the sudo configuration file of a several years old company and you have a good chance to see some proof for the rule that security is easily compromised by social problems, and that social problems cannot be solved by technical solutions alone. Instead, if you give people a tool like sudo which may be exploited or used in a wrong way, sooner or later it will pose a security thread.

"pfexec" is even worse. "sudo" does at least log every call in the system log, including the command it was started with. And, at least, it asks for the user password. "pfexec" does neither of this.

Have a look at this example, which is sometimes even called a "good practice" by some Sun representatives:


---
root@solcluster04:~> usermod -P '"Primary Administrator' rara
UX: usermod: rara is currently logged in, some changes may not take effect until next login.
root@solcluster04:~> grep rara /etc/user_attr
rara::::type=normal;profiles=Primary Administrator
root@solcluster04:~>
---


This assigns the "Primary Administrator" profile to the user "rara". It's the same procedure we did during the last part of our workshop, it's just another profile.
From now on, rara is able to do everything. He can even start a root shell by typing pfexec bash. The user's action won't be logged and you compromised your system (and, as a consequence, your network security) in the worst possible way.

I can't stress it enough:

Never use pfexec to distribute root privileges to regular non-root users. If a Sun representative or an external consultant recommends doing so, then show him where the exit is. If a colleague does it, show him/her how to do it better. If you do this yourself, please shoot a bullet into your brain.
Instead, insist on an active and effective password protection. sudo is not effective. Instead, use roles. We'll learn how to implement them in the next chapter.

There's a reason why sudo is not part of the Solaris distribution.

Posted by Ralf Ramge

In this chapter, we'll learn how we can grant the right to do specific actions which are by default "root only" to a single user.



Our goal: We want to give the user "rara" the right to create, delete and modify ZFS filesystems. The user will not be allowed to create or destroy Zpools.

Okay. how to achieve this? Well, it's pretty easy. Your Solaris system keeps a database which describes and bundles some actions into profiles. You can find this database here: /etc/security/exec_attr. It's plain ascii, so lets grep through it.


---
root@solcluster04:~> grep -i zfs /etc/security/exec_attr
ZFS File System Management:solaris:cmd:::/sbin/zfs:euid=0
ZFS Storage Management:solaris:cmd:::/sbin/zpool:uid=0
ZFS Storage Management:solaris:cmd:::/usr/lib/zfs/availdevs:uid=0
root@solcluster04:~>
---


Oh, this looks pretty good. We're lucky. We see three entries, which are bundled together into two different profiles:

- ZFS File System Management contains the command "/sbin/zfs". That's what the user "rara" needs.
- ZFS Storage Management ggrants access to the commands "/sbin/zpool" and "/usr/lib/zfs/availdevs". Oh no, that's evil, "rara" must not be allowed to use those.

Okay. Let's check if the user "rara" is allowed to manipulate ZFS file systems right now. He should not be able to do it.


---
bash-3.00$ /sbin/zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 158K 25.8G 24.5K /tank
bash-3.00$ /sbin/zfs create tank/test
cannot create 'tank/test': permission denied
bash-3.00$
---


Yes, he can issue a zfs list command, but not zfs create. That's the system default.

Let us connect "rara" to the ZFS File System Management profile we found. That's very simple:


---
root@solcluster04:~> usermod -P 'ZFS File System Management' rara
UX: usermod: rara is currently logged in, some changes may not take effect until next login.
root@solcluster04:~>
---


"rara" needs to log out and in again, so his new user profile is being activated. Okay, let's give it another try, perhaps he can create a ZFS now.


---
-bash-3.00$ /sbin/zfs create tank/test
cannot create 'tank/test': permission denied
-bash-3.00$
---


Oh. That was not expected, right? "rara" still isn't allowed to do what he wants to. But why? The answer is simple: because he acted as a common user. Let's check his data:


---
-bash-3.00$ id -a
uid=20499(rara) gid=100(users) groups=100(users)
-bash-3.00$
---


See? nothing has changed. The "zfs" command is still root only, but the uid of "rara" remained the same. Do you know the Linux command sudo? We're in the same situation. We need to tell Solaris that the "zfs" command should be run with root privileges. This is what "pfexec" is for.


---
-bash-3.00$ pfexec /sbin/zfs create tank/test
-bash-3.00$
---


No error message this time. Let's have a look at our filesystem list:


---
-bash-3.00$ /sbin/zfs list tank/test
NAME USED AVAIL REFER MOUNTPOINT
tank/test 24.5K 25.8G 24.5K /tank/test
-bash-3.00$
---


Very good. It worked.


Okay, what have we done:

Step 1: Search a matching profile in /etc/security/exec_attr
Step 2: Link the user to the profile by issuing a usermod command.

That's enough for today. In the next chapter, we'll talk a bit why this may be a simple, but also a very foolish way to grant rights to users.

Posted by Ralf Ramge

Several weeks ago, I explained why the combination of a X45x0 server, ZFS and AVS is a damn bad idea. On zfs-discuss, the discussion still rages on, but today somebody asked if AVS couldn't be a bit "smarter" and be more ZFS aware.

So the time has come to delve into the details once more. Again, I'll copy & paste it here to make sure that Google is aware of it, too. Perhaps it helps making ZFS even better.

Continue reading "AVS & ZFS: Great expectations"

Posted by Ralf Ramge

Hello everybody,

from time to time, I stumble over articles which focus on RBAC.

There are a lot of myths out there, most notably the story of RBAC being difficult to use.

And there are tons of bad pieces of advice out there, too. The most notorious one is the retarded idea of using pfexec as a password-less and thus "more convenient" security hole by allowing users to use root shells without further authentication. Meh.

Well, I thought about posting a small series of articles which show you how to use RBAC correctly and what you shouldn't try in your data center. And of course, I want you to see how darn easy it is. Believe me, it's a typical example for a Solaris technology: first it may look difficult and pretty useless, but once you took a closer look at it you won't understand how you could live without it.

We'll start with some "worst practices" which will give you a first insight how easy and comfortable RBAC could be, including pfexec.

After this, we'll learn how to do it properly by deploying a role which allows the use of "snoop" without changing to a root account.

Next, we'll learn how to allow specific users to restart a web service, while he's still not allowed to disable or enable the service.

And finally, we'll talk a little bit about profile shells and some other things you should know before you deploy those strategies in your live environment.

See you soon!

Posted by Ralf Ramge