Very Computer

Solaris 2.2, patch 100999-17 installed: I get a "Not owner" error when
e.g. trying to open a null device for writing if the device is on an NFS
filesystem:

# mount
/ on /dev/dsk/c0t3d0s0 read/write/setuid on Fri Aug 13 14:38:10 1993
...
/usr/local/scratch on super:/usr/local/scratch read/write/setuid/remote on Wed Aug 18 13:44:12 1993
# mknod /null c 13 2
# mknod /usr/local/scratch/null c 13 2
# chmod 666 /null /usr/local/scratch/null
# chown per /null /usr/local/scratch/null
# suspend

Stopped (signal)
% ls -l /devices/pseudo/mm:null  /null /usr/local/scratch/null
crw-rw-rw-   1 root     sys       13,  2 Aug 18 12:48 /devices/pseudo/mm:null
crw-rw-rw-   1 per      other     13,  2 Aug 18 13:44 /null
crw-rw-rw-   1 per      other     13,  2 Aug 18  1993 /usr/local/scratch/null
% echo xxx >/null
% echo xxx >/usr/local/scratch/null
/usr/local/scratch/null: Not owner
% whoami
per
%

Same thing appears to happen for all devices, pseudo or not. It works
fine for root. This would seem to be a problem for diskless clients...?
Patches, comments, explanations welcome!

--Per Hedeland


...uunet!erix.ericsson.se!per

I've tried lots of combinarions with devices and remote filesystems
(w or w/o remote root access, with anon=0, or with root=xx)
The only combination where devices didn't work was remote device
on a nosuid mounted filesystem (finally!).
But in that case the error would be:

/mnt/null: No such device or address.

Casper

Quote:>The only combination where devices didn't work was remote device
>on a nosuid mounted filesystem (finally!).

With Solaris 2, nosuid implies that device special files aren't honored
either. Another thing done right with Solaris 2.

        Wietse

|>
|> >Solaris 2.2, patch 100999-17 installed: I get a "Not owner" error when
|> >e.g. trying to open a null device for writing if the device is on an NFS
|> >filesystem:
|>
|> I've tried lots of combinarions with devices and remote filesystems
|> (w or w/o remote root access, with anon=0, or with root=xx)
|> The only combination where devices didn't work was remote device
|> on a nosuid mounted filesystem (finally!).

Umm, seems I neglected to mention a vital piece of information: The file
system was mounted from a host running SunOS 4.1.3... Any hope for that
situation? I seem to remember that Solaris/SVR4 has increased the space
for the major/minor number, but 13 and 2 should fit.:-) Is this a change
to the NFS protocol? (I have no idea how a device file is represented in
the protocol.)

--Per Hedeland


...uunet!erix.ericsson.se!per

Looking at the bits fly it seems that Solaris 2.x and SunOS 4.x clients
do pretty much thing when opening a device. Shells do a creat(file) when
redirecting stdout. This creat flies over the wire (this struck me as rather
odd, I though that all device handling was done in the kernel).

Anywy. What happens is that the Solaris 2.x clients sends a create
request over the wire that looks like this:

NFS:  File name = nul
NFS:  Mode = 020644
NFS:   Type = Character
NFS:   Setuid = 0, Setgid = 0, Sticky = 0
NFS:   Owner's permissions = rw-
NFS:   Group's permissions = r--
NFS:   Other's permissions = r--
NFS:  UID = -1
NFS:  GID = 0
NFS:  Size = 0
NFS:  Access time       = -1
NFS:  Modification time = -1
NFS:  

The SunOS 4.x clients sends this:

NFS:  File name = null
NFS:  Mode = 0644
NFS:   Type = ?
NFS:   Setuid = 0, Setgid = 0, Sticky = 0
NFS:   Owner's permissions = rw-
NFS:   Group's permissions = r--
NFS:   Other's permissions = r--
NFS:  UID = -1
NFS:  GID = 0
NFS:  Size = 0
NFS:  Access time       = -1
NFS:  Modification time = -1

The Solaris 2.x server code groks both. The SunOS 4.x server code doesn't like
the first one.

Casper

Beware that some seemingly harmless devices have different major and
minor numbers between sunos4 and sunos5 and trying to use sunos4
(/dev/zero, for example) can wreak havoc. Our anonymous ftp area had
the old /dev/zero, and ls (which mmaps /dev/zero) caused the kernel to
panic and crash. Whoops. The Sun people were very helpful in debugging
this problem.

Steve Rich
--
------------------------
Steve Rich

------------------------