Blog Archives

What do you do when the permissions on your mount point are wrong? I got asked this today as one of my colleagues was trying to recover from bug 4992478. I was slightly surprised that everyone who has ever done SunOS system admin did not know this.

The whole symptoms of this are bizarre. Users can’t do things that they should be able to do: eg:

Sun Microsystems Inc.   SunOS 5.11      snv_21  October 2007 : v4u-4000d-gmp03.eu TS 1 $; cat /etc/nodename v4u-4000d-gmp03 : v4u-4000d-gmp03.eu TS 2 $; cat /foo/../etc/nodename cat: cannot open /foo/../etc/nodename : v4u-4000d-gmp03.eu TS 3 $; ls -la /foo /foo/..: Permission denied total 18 drwxr-xr-x   3 root     root         512 Sep 16 12:36 . drwx——   2 root     root        8192 Sep 16 12:36 lost+found : v4u-4000d-gmp03.eu TS 4 $;

This came about because I did this when I mounted the file system:

v4u-4000d-gmp03 393 # mkdir -m 700 /foo v4u-4000d-gmp03 394 # mount /dev/dsk/c3t1d0s2 /foo v4u-4000d-gmp03 395 #

The permissions on the directory that is being covered by the mount point are to restrictive. So how can you fix that? Clearly unmounting “/foo” and then doing “chmod 755 /foo” would do it but what if you can’t unmount the file system?

Here is one way, without resorting to fsdb:

v4u-4000d-gmp03 503 # share -F nfs -o rw=localhost,root=localhost / v4u-4000d-gmp03 504 # mount -o vers=3 127.0.0.1:/ /fix/mnt v4u-4000d-gmp03 505 # chmod 755  /fix/mnt/foo v4u-4000d-gmp03 506 # chmod 700  /fix/mnt/foo v4u-4000d-gmp03 507 # umount  /fix/mnt v4u-4000d-gmp03 508 # rmdir -p  /fix/mnt v4u-4000d-gmp03 509 # mkdir -p  /fix/mnt v4u-4000d-gmp03 510 # chmod 700 /fix v4u-4000d-gmp03 511 # share -F nfs -o rw=localhost,root=localhost / v4u-4000d-gmp03 512 # mount -o vers=3 127.0.0.1:/ /fix/mnt v4u-4000d-gmp03 513 # chmod 755  /fix/mnt/foo v4u-4000d-gmp03 514 # umount  /fix/mnt v4u-4000d-gmp03 515 # unshare / v4u-4000d-gmp03 516 #

and now all is well for the users:

: v4u-4000d-gmp03.eu TS 4 $;  ls -la /foo total 20 drwxr-xr-x   3 root     root         512 Sep 16 12:36 . drwxr-xr-x  32 root     root        1024 Sep 16 13:47 .. drwx——   2 root     root        8192 Sep 16 12:36 lost+found : v4u-4000d-gmp03.eu TS 5 $; cat /foo/../etc/nodename v4u-4000d-gmp03 : v4u-4000d-gmp03.eu TS 6 $;

Obviously we are playing fast an loose with nfs as we all know that you should not do local NFS mounts, so the proper way would be to use another system to act as the client, but the risk is small and made smaller by me making “/fix” mode 700, although there is a race in the order I ran the above commands, but hey this is a blog not a text book.

One odd thing is that this does not work “out of the box” with NFS v4, need to think about that one.

Tags: topic:[solaris] topic:[SunOS] topic:[UNIX] topic:[NFS] topic:[sysadmin]

Coreadm(1m) has a really nice feature that can be used to restrict coredumps that are collected to just the one from the system. Typically I’m not interested in a global core file from and application that someone is developing so I would like to limit the cores to just those created by programs that are delivered as part of solaris.

So if you use %d as part of the pattern it will expand to the name of the directory where the binary lives. If the directory does not exist then no core file.

So in this example if /usr/bin/ls were to dump core (not that it does) using this setup:

 # coreadm
     global core file pattern: /var/cores/%d/%f.%p.%u
     global core file content: default
       init core file pattern: core
       init core file content: default
            global core dumps: enabled
       per-process core dumps: enabled
      global setid core dumps: disabled
 per-process setid core dumps: disabled
     global core dump logging: enabled
# 

The global core only gets dumped if /var/cores/usr/bin exists.

The down side of this is that not all the executables you may be interested in are in /usr/bin or other obvious locations so they could fail to dump core as the directory does not yet exist.

So I knocked together this little script to create all the directories that I will ever need:

nawk ‘$2 == “f” { printf(“file %sn”, $1) }’  /var/sadm/install/contents |
ksh -p |
nawk ‘function dirname(path) {
        len= length(path);
        for (n = 1 ; index(substr(path, len – (1+ n), n), “/”) == 0; n++) ;

return(substr(path, 1, len – (2+ n)));
}
/ELF.*executable/ {
x[dirname($1)]=1
}
END {
for (y in x ) {
printf(“test -d /var/cores%s || mkdir -p /var/cores%sn”,
y, y)
}
}’ | ksh -x

My suspicion is that there is probably a better way. So let me know.

Tags: topic:[solaris] topic:[coreadm]