Unexpected chown behaviour (Guru needed)

Unexpected chown behaviour (Guru needed)

Post by Udo Grabowsk » Wed, 13 Nov 2002 02:41:35



Hello managers!

We encountered an unexpected problem when trying to give a file
from one user to another. After failing with plain Solaris 8, we
have set rstchown to 0 in /etc/system, and transferring files to
another user work as expected when doing this on files automounted
from the local host. But it still does not work on files on a
(remote) NFS-mounted filesystem, in spite of having it mounted rw,suid.
Of course granting user has write permission in directory, owns the
file, and target user has the same group as granting user, and has
also write permission (even group write permission is on). None can
chown, as if the POSIX parameter was not set at all.

Is there another parameter to set ? Is this completely forbidden ?
Any idea to trick out chown to get that working ?

(Yes, we know that this is considered to be insecure, but we need it,
and we are behind several firewalls)

Thanks for any help !
--

Institut f. Meteorologie und Klimaforschung II, Forschungszentrum Karslruhe
Postfach 3640, D-76021 Karlsruhe, Germany           Tel: (+49) 7247 82-6026
http://www.fzk.de/imk/imk2/ame/grabowski/           Fax:         "    -6141

 
 
 

Unexpected chown behaviour (Guru needed)

Post by Jimm » Wed, 13 Nov 2002 03:34:20



> We encountered an unexpected problem when trying to give a file
> from one user to another. After failing with plain Solaris 8, we
> have set rstchown to 0 in /etc/system, and transferring files to
> another user work as expected ... But it still does not work on
> files on a (remote) NFS-mounted filesystem, in spite of having
> it mounted rw,suid.

The chown request is passed to the NFS server and if that
doesn't have rstchown=0, then the request will be denied.
It worked on the locally automounted case because it's
the local machine making the decision and you had disabled
the default behaviour.

Quote:> (Yes, we know that this is considered to be insecure, but we need it,
> and we are behind several firewalls)

What about your own evil and wicked users? :)

-Jimmo

 
 
 

Unexpected chown behaviour (Guru needed)

Post by Casper H.S. Di » Wed, 13 Nov 2002 05:56:41



>from one user to another. After failing with plain Solaris 8, we
>have set rstchown to 0 in /etc/system, and transferring files to
>another user work as expected when doing this on files automounted
>from the local host. But it still does not work on files on a
>(remote) NFS-mounted filesystem, in spite of having it mounted rw,suid.
>Of course granting user has write permission in directory, owns the
>file, and target user has the same group as granting user, and has
>also write permission (even group write permission is on). None can
>chown, as if the POSIX parameter was not set at all.
>Is there another parameter to set ? Is this completely forbidden ?
>Any idea to trick out chown to get that working ?

The parameter also needs to be set on the NFS server; it owns the files
and it determines the policy which applies to the files on the
system.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

Unexpected chown behaviour (Guru needed)

Post by Udo Grabowsk » Wed, 13 Nov 2002 17:50:00


Thanks for the hint. I suspected something like that.
Now the tricky part: The exporting server is a Tru64
machine, and I did not find any way to allow non-root
chowns on exported filesystems. Looks like this is
the end of my attempts.
--

Institut f. Meteorologie und Klimaforschung II, Forschungszentrum Karslruhe
Postfach 3640, D-76021 Karlsruhe, Germany           Tel: (+49) 7247 82-6026
http://www.fzk.de/imk/imk2/ame/grabowski/           Fax:         "    -6141
 
 
 

Unexpected chown behaviour (Guru needed)

Post by Casper H.S. Di » Wed, 13 Nov 2002 18:59:53



>Thanks for the hint. I suspected something like that.
>Now the tricky part: The exporting server is a Tru64
>machine, and I did not find any way to allow non-root
>chowns on exported filesystems. Looks like this is
>the end of my attempts.

Does it have a system wide knob?

(In Solaris this is documented in the chown(2) manual page; there's
a reference to _POSIX_CHOWN_RESTRICTED in the Tru64 manual pages
as google will turn them up, but no hint how to change it)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

1. Idea for modifying chown()s behaviour

Hi all,

Some versions of the chown function (e.g., at least one of
the BSDs) change to the specified directory before performing
the chown, thus preventing programs from breaking out of a
chroot jail.

This behaviour isn't mandated by POSIX et el, so Solaris
and other conformant OSes don't do this.  Chroot merely sets
the root directory, leaving us in the current directory
(whatever that may be).

This is all fine, but about implementing a kernel variable
switch that allows the kind of behaviour to be toggled,
a bit like the use of chown (rstchown).

A kernel variable, say posix_chroot could be introduced,
defaulting to 1 which would be the current behaviour.
However, setting it to 0 would cause the current directory
to be changed to the new chrooted directory.

What do people think?

--
Rich Teer

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

2. Annoying intellimouse problems

3. chown inconsistent behaviour?

4. books on bsd?

5. Unexpected behaviour on UDP ports

6. S/key and AIX

7. Bridge + Netfilter unexpected behavior

8. Serial Device file creation (/dev/cua?)

9. Unexpected behavior by 'tc'

10. Unexpected scheduler behaviour ?

11. Unexpected behaviour with create_module

12. 1 * vBuPXfkBZ-Unexpected behaviour of cpio in Solaros 2.6?

13. Chown: Can non-root user chown?