Skip to content

chmod octal form of sgid/suid removal fails

The was a disturbance in the force today:
$ mkdir dir
$ touch file
$ chmod +s dir file
$ ls -l
drwsr-sr-x 2 root root 4096 Apr 30 11:54 dir
-rwSr-Sr-- 1 root root    0 Apr 30 11:54 file

$ chmod 0750 dir
$ chmod 0640 file
$ ls -l
drwsr-s--- 2 root root 4096 Apr 30 11:54 dir
-rw-r----- 1 root root    0 Apr 30 11:54 file
Yes, this is even documented behaviour and conforms to POSIX as well - still, I find it far from being intuitive. There's a quite an interesting posting at the bug-coreutils list, stating:
> This topic came up when I first added that feature, and originally I
> agreed with you, but others did not and their arguments were
> persuasive.  The counterargument is that it's strange if a leading
> zero changes the semantics of a number, as this is not what many
> people expect.
...mentioning an earlier discussion on the same list. Oh well...

mod_mime_magic: invalid type 0 in mconvert()

I remember having these messages in my Apache logs before:
mod_mime_magic: type search/400\t\\\\section\ttext/x-tex invalid
mod_mime_magic: type search/400\t\\\\setlength\ttext/x-tex invalid
[...]
mod_mime_magic: invalid type 0 in mconvert().
....and I even remember setting up a workaround for this one. Now, years later this issue comes up again. Here's a rather ugly, semi-automatic attempt to remediate this (cosmetic) error:
$ awk '/mod_mime_magic:.*invalid$/ {print $9}' /var/log/apache2/error.log | \
   sort -u | \
   sed -e 's/search\/400.*\\\\/search\/400.*/;s/^regex.*tory\\t/regex.*/;\
   s/\//./g'  > /tmp/1
$ mkdir /usr/local/share/file/
$ cp /usr/share/file/magic.mime /usr/local/share/file/
$ for i in `cat /tmp/1`; do
     sed "s/^.*$i/# &/" -i /usr/local/share/file/magic.mime
  done
Now we can point MIMEMagicFile in mime_magic.conf to the new magic file and the errors should go away. Of course, fixing libmagic1 would be cool too :-)

HFS+

I just noticed that I could not chown files on this newly created HFS+ disk. Using diskutil, I could only see a few noteworthy differences:
$ diskutil info /
[...]
   File System:       Journaled HFS+
                      Journal size 8192 k at offset 0xe2000
   Owners:            Enabled
   Partition Type:    Apple_HFS
   Protocol:          ATA

$ diskutil info /Volumes/disk4
[...]
   File System:       Journaled HFS+
                      Journal size 81920 k at offset 0x1d1e000
   Owners:            Disabled
   Partition Type:    Apple_HFS
   Protocol:          Disk Image
As someone else suggested, I was able to use vsdbutil to enable ownerships/permissions again:
$ mount | grep /Volumes/disk4
/dev/disk4 on /Volumes/disk4 (hfs, local, nodev, nosuid, journaled, noowners)

$ vsdbutil -a /Volumes/disk4
$ vsdbutil -c /Volumes/disk4
Permissions on '/Volumes/disk4' are enabled.

$ mount | grep /Volumes/disk4
/dev/disk4 on /Volumes/disk4 (hfs, local, nodev, nosuid, journaled)

raw disk access in VirtualBox

With VirtualBox being the only open source virtualization suite for MacOS X at the moment, I'm running it from time to time to test new stuff. Currently there's a two disk storage box standing at my desk and I wanted to attach both disks to a VirtalBox Guest OS. Although documented in the manual and in the blogosphere, I found it hard to find the (few) commands needed to do this:
darwin$ diskutil list
[...]
/dev/disk3
   #:                  TYPE NAME              SIZE       IDENTIFIER
   0:      GUID_partition_scheme             *931.5 Gi   disk3
   1:       Microsoft Basic Data              931.5 Gi   disk3s1

darwin$ VBoxManage internalcommands createrawvmdk \
            -filename disk0.vmdk -rawdisk /dev/disk3 -register
The resulting .vmdk file will only hold metadata but not contain any actual data - exactly what we want :-)

Oh, and while we're at it: disk performance sucks in MacOS X. IMHO, sequential read/write bandwidth from/to the raw device should only be limited by its HBA respectively the device attached to it. Well, this SATA disk (WD10EACS) is specified with 3Gb/s or ~375 MB/s and is attached via Firewire 800 which in turn should be able to deliver speeds up to 100MB/s. But under MacOS 10.5 (fully patched), dd only scores ~16MB/s. It's good to know though that the VirtualBox Guest OS (Linux 2.6) with raw access to this disk is receiving these 16MB/s as well, so no overhead here. Accessing the same disk on the same box (iMac, MB323LL/A) natively under Linux 2.6 gives us ~66MB/s - a far more reasonable number.

Resizing a VMware disk for WinXP

This WindowsXP installation in VMware Server virtual machine was low on diskspace. So I looked at vmware-vdiskmanager which comes with VMware Server to resize the boot disk. The fact that my VMware disk was split into 2 GB slices (sigh) did not matter at all:
# ls -lgoh *vmdk
-rw------- 1 1.9G 2009-04-22 20:25 winxp-s001.vmdk
-rw------- 1 2.0G 2009-04-22 20:25 winxp-s002.vmdk
-rw------- 1 706M 2009-04-22 20:25 winxp-s003.vmdk
-rw------- 1  457 2009-04-22 20:11 winxp.vmdk

# vmware-vdiskmanager -x 6GB winxp.vmdk
Using log file /tmp/vmware-root/vdiskmanager.log
The old geometry C/H/S of the disk is: 9752/16/63
The new geometry C/H/S of the disk is: 12483/16/63
Disk expansion completed successfully.

# ls -lgoh *vmdk
-rw------- 1 1.9G 2009-04-22 20:25 winxp-s001.vmdk
-rw------- 1 2.0G 2009-04-22 20:25 winxp-s002.vmdk
-rw------- 1 706M 2009-04-22 20:25 winxp-s003.vmdk
-rw------- 1 415M 2009-04-22 20:25 winxp-s004.vmdk
-rw------- 1  457 2009-04-22 20:11 winxp.vmdk
I guess these are sparse images, growing dynamically in size. Now, we still have to tell WinXP that its boot disk has been resized. As it is the boot disk and we cannot use WinXP magic, I've decided to go with the GParted LiveCD. However, booting failed with strange SCSI errors. Chaning the VMware SCSI driver helped: simply set/add scsi0.virtualDev = "lsilogic" to your .vmx file - now GParted was booting and I was able to resize the parition. After doing that I found a resize-windows.txt on the LiveCD, stating that WinXP may have a problem when partition sizes change. Well, too late for that no as I already resized the disk. Luckily, WinXP was booting (after a chkdsk run has been forced), presenting me with a 6GB C: drive - nice :)

error: offset '3' outside bounds of constant string

When compiling the latest ZFS-on-FUSE checkout, GCC (Debian/sid, 4.4-20090329-1) barfs with:
cc1: warnings being treated as errors
lib/libzfs/libzfs_dataset.c: In function 'zfs_prop_get':
lib/libzfs/libzfs_dataset.c:2348: error: offset '3' outside bounds of constant string
lib/libzfs/libzfs_dataset.c:2355: error: offset '3' outside bounds of constant string
scons: *** [lib/libzfs/libzfs_dataset.o] Error 1
scons: building terminated because of errors.
As this is really a gcc bug, we'd have to wait for a real fix. But we're impatient and there are two workarounds here:
1) compile w/o optimizations (i.e. no -On options)
2) compile w/o the -Werror flag.
The latter is probably what you want here...

chroot SSH login on MacOS 10.4

While I was looking for a chroot'ed SSH setup on MacOS X, I've came a cross a few postings but most of them were basically "yeah, it's hard, and you have to recompile, bla..." or were dealing with sftp/scp - not what I wanted. I really want users to get an interactive shell, but not snoop around on the real filesystem. Here's a short howto:
$ sudo su -
$ port install jailkit
$ mkdir -p /mnt/chroot/usr/bin /mnt/chroot/usr/lib/system /mnt/chroot/etc \
           /mnt/chroot/home /mnt/chroot/dev/fd /mnt/chroot/home/dummy
$ chown -R root:wheel /mnt/chroot
$ ln /bin/bash /mnt/chroot/bin/bash
$ ln /usr/bin/telnet /mnt/chroot/usr/bin/telnet
$ cp -R /usr/lib/libncurses*dylib /mnt/chroot/usr/lib
$ cp /usr/lib/libSystem.B.dylib /mnt/chroot/usr/lib
$ cp /usr/lib/system/libmathCommon.A.dylib /mnt/chroot/usr/lib/system
Note: there's no ldd in MacOS X, but we can use otool to list dynamic (library) dependencies:
$ otool -L /bin/bash 
/bin/bash:
        /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0)
Be aware that these dependencies may have dependencies on its own, you can do something like this to grab all of them - although it's not entirely recursive.

We're not quite ready yet:
  • create a user ("dummy") via NetInfo Manager.app, set a password.
  • set her home to /mnt/chroot/./home/dummy
  • set her shell to /opt/local/sbin/jk_chrootsh
  • create an /etc/passwd inside the jail
$ id -u dummy
505
$ echo "dummy:x:505:505::/home/dummy:/bin/bash" > /mnt/chroot/etc/passwd
$ chown -R dummy:dummy /mnt/chroot/home/dummy
And for the sake of completenes, we're even creating a few devicefiles:
$ cp -R /dev/fd/[012] /mnt/chroot/dev/fd
$ cp -R /dev/std* /dev/null /dev/zero /dev/tty /dev/*random /mnt/chroot/dev
Now everything should be in its place. jk_chrootsh is *very* picky about ownership/permissions (rightfully so!) and when something goes wrong, it logs to auth.log, e.g.:
  abort, home directory /dummy differs from jail home directory 
   /mnt/chroot/./dummy for user dummy (505),
   check /etc/passwd and /mnt/chroot/etc/passwd
or
  ERROR: failed to execute shell /bin/bash for user dummy (505), 
  check the permissions and libraries of /mnt/chroot//bin/bash
NB: Tiger's OpenSSH_5.1p1 comes with an option called ChrootDirectory for quite a while now. And after struggling with the procedure above (sigh...), this option looks quite comfortable:
Match user dummy
    ChrootDirectory /mnt/chroot
This worked for me after two small fixes:
$ chown root:wheel /
$ chmod 0755 /
Btw, for a few weeks now SunSSH does support this option too in OpenSolaris. Nice :)