* NFS root manipulation without being superuser?
@ 2002-11-15 16:37 Jeff Kowing
2002-11-15 18:48 ` Brian Waite
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Kowing @ 2002-11-15 16:37 UTC (permalink / raw)
To: linuxppc-embedded
During embedded system developement, I use an NFS root mounted
filesystem that is exported from my development workstation. I am
constantly having to "su root" on my development workstation when I
want to manipulate the root filesystem for the target machine. I was
wondering if anyone uses a safer technique that allows manipulation of
the target's root filesystem without being root on the development
workstation.
I know I could make the exported filesystem all be owned by my
unprivledged user and group name, but I would like the target machine
to see those files as owned by root as would normally be the case.
Anyways, I was just curious if I am missing out on some cool technique
that other's use that I am not brilliant enough to come up with on my
own.
Thanks.
--
Jeff Kowing
jeffrey.d.kowing@nasa•gov
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NFS root manipulation without being superuser?
2002-11-15 16:37 NFS root manipulation without being superuser? Jeff Kowing
@ 2002-11-15 18:48 ` Brian Waite
2002-11-15 19:58 ` Jeff Kowing
0 siblings, 1 reply; 8+ messages in thread
From: Brian Waite @ 2002-11-15 18:48 UTC (permalink / raw)
To: jeffrey.d.kowing; +Cc: linuxppc-embedded
you could export the fs from the dev host as no_root_squash an insecure
for example
/home *(rw,insecure,no_root_squash)
That will allow the embedded host to modify files on the NFS filesystem as
root. Does tha accomplish what you need?
Thanks
Brian
On Friday 15 November 2002 11:37 am, Jeff Kowing wrote:
> During embedded system developement, I use an NFS root mounted
> filesystem that is exported from my development workstation. I am
> constantly having to "su root" on my development workstation when I
> want to manipulate the root filesystem for the target machine. I was
> wondering if anyone uses a safer technique that allows manipulation of
> the target's root filesystem without being root on the development
> workstation.
>
> I know I could make the exported filesystem all be owned by my
> unprivledged user and group name, but I would like the target machine
> to see those files as owned by root as would normally be the case.
>
> Anyways, I was just curious if I am missing out on some cool technique
> that other's use that I am not brilliant enough to come up with on my
> own.
>
> Thanks.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NFS root manipulation without being superuser?
2002-11-15 18:48 ` Brian Waite
@ 2002-11-15 19:58 ` Jeff Kowing
2002-11-15 20:24 ` Chris Hallinan
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Kowing @ 2002-11-15 19:58 UTC (permalink / raw)
To: Brian Waite; +Cc: linuxppc-embedded
Brian Waite writes:
> you could export the fs from the dev host as no_root_squash an insecure
> for example
> /home *(rw,insecure,no_root_squash)
>
> That will allow the embedded host to modify files on the NFS filesystem as
> root. Does tha accomplish what you need?
Thanks Brain for the reply. No, that is not really what I mean. I
want to be able to manipulate/create/alter the target's root
filesystem (exported from the development workstation) from the
_development_ workstation. I want to be able to do so without having
to change to superuser privleges on the development workstation.
For example, say I export an NFS root filesystem to my target. This
filesystem on my development machine is located within my home
directory. For example:
/home/me/target
/home/me/target/bin
/home/me/target/root
/home/me/target/lib
/home/me/target/dev
... you get the idea.
Now, from my development workstation, as user "me", I would like to be
able to install a program to the target's NFS root filesystem. I
would like that program to appear as having root ownership to the
target. For example, user "me" installs the program "foo" to:
/home/me/target/bin/foo
On the development machine this would look like:
developmentt$ ls -l /home/me/target/bin/foo
-rwxr-xr-x 1 me me 48 Nov 15 10:59 foo
On the target machine this would look like:
target$ ls -l /bin/foo
-rwxr-xr-x 1 root root 48 Nov 15 10:59 foo
I guess maybe I thought there might be a way to do some sort of NFS
user/group mapping so that you could "trick" the target into thinking
files were owned by root whereas on the development machine they are
in reality owned by user "me". Or some sort of tricks that could be
played using fakeroot and those kinds of programs.
I guess what I really want is a way, from my development workstation,
to have the "power" of root to manipulate the target's filesystem
(i.e., the files under /home/me/target directory) WITHOUT having the
"power" to screw up the development workstation's system files. Does
this make sense to anyone or is the caffeine affecting my thinking?
--
Jeff Kowing
jeffrey.d.kowing@nasa•gov
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: NFS root manipulation without being superuser?
2002-11-15 19:58 ` Jeff Kowing
@ 2002-11-15 20:24 ` Chris Hallinan
0 siblings, 0 replies; 8+ messages in thread
From: Chris Hallinan @ 2002-11-15 20:24 UTC (permalink / raw)
To: jeffrey.d.kowing, Brian Waite; +Cc: linuxppc-embedded
Maybe this is just too simple, but I always have my target file
system under my home directory or under /opt with user:group ==
me:swdev, or something like that, and who cares what the target
thinks the user:group is, because I always login as root on my
target. So, that way, I can do what you seek: 1) have the Power of
God on my own development workstation's 'target file system' to make
changes as I see fit, 2) not risk wiping out something on my
workstation (which I've done, yes :) and 3) modify the target fs
from my target, as well!
I *NEVER, NEVER, NEVER work routinely as root! <grin>
Does that make sense?
-Chris Hallinan
DS4.COM, Inc.
> -----Original Message-----
> From: owner-linuxppc-embedded@lists•linuxppc.org
> [mailto:owner-linuxppc-embedded@lists•linuxppc.org]On
> Behalf Of Jeff
> Kowing
> Sent: Friday, November 15, 2002 2:59 PM
> To: Brian Waite
> Cc: linuxppc-embedded@lists•linuxppc.org
> Subject: Re: NFS root manipulation without being superuser?
>
>
>
> Brian Waite writes:
> > you could export the fs from the dev host as
> no_root_squash an insecure
> > for example
> > /home *(rw,insecure,no_root_squash)
> >
> > That will allow the embedded host to modify files on
> the NFS filesystem as
> > root. Does tha accomplish what you need?
>
> Thanks Brain for the reply. No, that is not really what
> I mean. I
> want to be able to manipulate/create/alter the target's root
> filesystem (exported from the development workstation) from the
> _development_ workstation. I want to be able to do so
> without having
> to change to superuser privleges on the development workstation.
>
> For example, say I export an NFS root filesystem to my
> target. This
> filesystem on my development machine is located within my home
> directory. For example:
>
> /home/me/target
> /home/me/target/bin
> /home/me/target/root
> /home/me/target/lib
> /home/me/target/dev
> ... you get the idea.
>
> Now, from my development workstation, as user "me", I
> would like to be
> able to install a program to the target's NFS root filesystem. I
> would like that program to appear as having root ownership to the
> target. For example, user "me" installs the program "foo" to:
>
> /home/me/target/bin/foo
>
> On the development machine this would look like:
> developmentt$ ls -l /home/me/target/bin/foo
> -rwxr-xr-x 1 me me 48 Nov 15 10:59 foo
>
> On the target machine this would look like:
> target$ ls -l /bin/foo
> -rwxr-xr-x 1 root root 48 Nov 15 10:59 foo
>
> I guess maybe I thought there might be a way to do some
> sort of NFS
> user/group mapping so that you could "trick" the target
> into thinking
> files were owned by root whereas on the development
> machine they are
> in reality owned by user "me". Or some sort of tricks
> that could be
> played using fakeroot and those kinds of programs.
>
> I guess what I really want is a way, from my development
> workstation,
> to have the "power" of root to manipulate the target's filesystem
> (i.e., the files under /home/me/target directory) WITHOUT
> having the
> "power" to screw up the development workstation's system
> files. Does
> this make sense to anyone or is the caffeine affecting my
> thinking?
>
> --
> Jeff Kowing
> jeffrey.d.kowing@nasa•gov
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <0060C09C.C21188@nasa.gov>]
* Re: NFS root manipulation without being superuser?
[not found] <0060C09C.C21188@nasa.gov>
@ 2002-11-15 20:16 ` Jerry Van Baren
2002-11-15 21:51 ` William A. Gatliff
0 siblings, 1 reply; 8+ messages in thread
From: Jerry Van Baren @ 2002-11-15 20:16 UTC (permalink / raw)
To: linuxppc-embedded
How about this thought... on your development system, make a group "xroot"
(export root, or maybe name it "grub" to make a bad pun) and chown your NFS
files currently owned by "root" to "xroot". You can add yourself into the
"xroot" group and make sure all the NFS exported root file system have
group r/w privileges. Now you can play with the files to your heart's
content because you are part of the group that has write permissions. When
you are happy with your NFS exported root file system, change the group
ownership of "xroot" back to "root". With a little thought and a lot of
care ;-), you should be able to write a script that does the group change
back & forth.
gvb
At 01:58 PM 11/15/2002 -0500, jeffrey.d.kowing@nasa•gov wrote:
>Brian Waite writes:
> > you could export the fs from the dev host as no_root_squash an insecure
> > for example
> > /home *(rw,insecure,no_root_squash)
> >
> > That will allow the embedded host to modify files on the NFS filesystem as
> > root. Does tha accomplish what you need?
>
>Thanks Brain for the reply. No, that is not really what I mean. I
>want to be able to manipulate/create/alter the target's root
>filesystem (exported from the development workstation) from the
>_development_ workstation. I want to be able to do so without having
>to change to superuser privleges on the development workstation.
>
>For example, say I export an NFS root filesystem to my target. This
>filesystem on my development machine is located within my home
>directory. For example:
>
>/home/me/target
>/home/me/target/bin
>/home/me/target/root
>/home/me/target/lib
>/home/me/target/dev
>... you get the idea.
>
>Now, from my development workstation, as user "me", I would like to be
>able to install a program to the target's NFS root filesystem. I
>would like that program to appear as having root ownership to the
>target. For example, user "me" installs the program "foo" to:
>
>/home/me/target/bin/foo
>
>On the development machine this would look like:
>developmentt$ ls -l /home/me/target/bin/foo
>-rwxr-xr-x 1 me me 48 Nov 15 10:59 foo
>
>On the target machine this would look like:
>target$ ls -l /bin/foo
>-rwxr-xr-x 1 root root 48 Nov 15 10:59 foo
>
>I guess maybe I thought there might be a way to do some sort of NFS
>user/group mapping so that you could "trick" the target into thinking
>files were owned by root whereas on the development machine they are
>in reality owned by user "me". Or some sort of tricks that could be
>played using fakeroot and those kinds of programs.
>
>I guess what I really want is a way, from my development workstation,
>to have the "power" of root to manipulate the target's filesystem
>(i.e., the files under /home/me/target directory) WITHOUT having the
>"power" to screw up the development workstation's system files. Does
>this make sense to anyone or is the caffeine affecting my thinking?
>
>--
>Jeff Kowing
>jeffrey.d.kowing@nasa•gov
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: NFS root manipulation without being superuser?
2002-11-15 20:16 ` Jerry Van Baren
@ 2002-11-15 21:51 ` William A. Gatliff
2002-11-15 22:42 ` Jerry Van Baren
0 siblings, 1 reply; 8+ messages in thread
From: William A. Gatliff @ 2002-11-15 21:51 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-embedded
Jerry:
On Fri, Nov 15, 2002 at 03:16:16PM -0500, Jerry Van Baren wrote:
>
> How about this thought... on your development system, make a group "xroot"
> (export root, or maybe name it "grub" to make a bad pun)
How about "tuber"? :^)
> and chown your NFS files currently owned by "root" to "xroot". You
> can add yourself into the "xroot" group and make sure all the NFS
> exported root file system have group r/w privileges. Now you can
> play with the files to your heart's content because you are part of
> the group that has write permissions. When you are happy with your
> NFS exported root file system, change the group ownership of "xroot"
> back to "root". With a little thought and a lot of care ;-), you
> should be able to write a script that does the group change back &
> forth.
Maybe just this:
# cd <nfs-root-dir> && find . -name "*" | xargs chown xroot:xroot
What about the files that the client creates or modifies,
i.e. resolv.conf in a DHCP setting? I think those files will still
get created with root ownership. It's almost as if NFS needs
translate the UID of the files both inbound and outbound.
Other than that, your suggestion looks great.
b.g.
--
Bill Gatliff
Do you do embedded GNU? I do!
See http://billgatliff.com for details.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NFS root manipulation without being superuser?
2002-11-15 21:51 ` William A. Gatliff
@ 2002-11-15 22:42 ` Jerry Van Baren
0 siblings, 0 replies; 8+ messages in thread
From: Jerry Van Baren @ 2002-11-15 22:42 UTC (permalink / raw)
To: linuxppc-embedded
Tuber. I like that :-).
My suggestion was slightly different from your script:
1) Your script is going to chown _all_ the exported files. That is bad.
2) I would change only the _group_, not the owner. This will prevent
breaking SUID programs.
Your oneliner (UNTESTED) would then be:
# cd <nfs-root-dir> && find . -uid 0 | xargs chgrp xroot
and changing back would be:
# cd <nfs-root-dir> && find . -uid 0 | xargs chgrp root
Note that, since the owner doesn't change, it is easy to mess with only the
root-owned files.
With respect to newly created files, I don't have a good solution, but the
above script would be simple to fix them up again. You could even use
"-uid 0 -gid 0" to find only the newly created ones.
gvb
At 03:51 PM 11/15/2002 -0600, William A. Gatliff wrote:
>Jerry:
>
>On Fri, Nov 15, 2002 at 03:16:16PM -0500, Jerry Van Baren wrote:
> >
> > How about this thought... on your development system, make a group "xroot"
> > (export root, or maybe name it "grub" to make a bad pun)
>
>How about "tuber"? :^)
>
> > and chown your NFS files currently owned by "root" to "xroot". You
> > can add yourself into the "xroot" group and make sure all the NFS
> > exported root file system have group r/w privileges. Now you can
> > play with the files to your heart's content because you are part of
> > the group that has write permissions. When you are happy with your
> > NFS exported root file system, change the group ownership of "xroot"
> > back to "root". With a little thought and a lot of care ;-), you
> > should be able to write a script that does the group change back &
> > forth.
>
>Maybe just this:
>
># cd <nfs-root-dir> && find . -name "*" | xargs chown xroot:xroot
>
>What about the files that the client creates or modifies,
>i.e. resolv.conf in a DHCP setting? I think those files will still
>get created with root ownership. It's almost as if NFS needs
>translate the UID of the files both inbound and outbound.
>
>Other than that, your suggestion looks great.
>
>
>b.g.
>--
>Bill Gatliff
>Do you do embedded GNU? I do!
>See http://billgatliff.com for details.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: NFS root manipulation without being superuser?
@ 2002-11-16 0:31 Rod Boyce
0 siblings, 0 replies; 8+ messages in thread
From: Rod Boyce @ 2002-11-16 0:31 UTC (permalink / raw)
To: 'Chris Hallinan', jeffrey.d.kowing, Brian Waite; +Cc: linuxppc-embedded
I do this for all our developers they each have a target directory under
their home directory. It is shared as rw no_root_squash you login as root
on the target but can only stuff up your home directory.
The target directory is created when I create a new user account. This
works well for us. We have about 12 developers using the same machine for
development and their target machines for testing. The server does not have
to be reboot very often but sometime you get a rogue application.
We use the standard RH user groups if a user makes a stuff up in this target
directory then I chown it back to his user or copy from the skel directory
over the top and perform a chown.
Rod
-----Original Message-----
From: Chris Hallinan [mailto:clh@net1plus•com]
Sent: Friday, November 15, 2002 12:25 PM
To: jeffrey.d.kowing@nasa•gov; Brian Waite
Cc: linuxppc-embedded@lists•linuxppc.org
Subject: RE: NFS root manipulation without being superuser?
Maybe this is just too simple, but I always have my target file
system under my home directory or under /opt with user:group ==
me:swdev, or something like that, and who cares what the target
thinks the user:group is, because I always login as root on my
target. So, that way, I can do what you seek: 1) have the Power of
God on my own development workstation's 'target file system' to make
changes as I see fit, 2) not risk wiping out something on my
workstation (which I've done, yes :) and 3) modify the target fs
from my target, as well!
I *NEVER, NEVER, NEVER work routinely as root! <grin>
Does that make sense?
-Chris Hallinan
DS4.COM, Inc.
> -----Original Message-----
> From: owner-linuxppc-embedded@lists•linuxppc.org
> [mailto:owner-linuxppc-embedded@lists•linuxppc.org]On
> Behalf Of Jeff
> Kowing
> Sent: Friday, November 15, 2002 2:59 PM
> To: Brian Waite
> Cc: linuxppc-embedded@lists•linuxppc.org
> Subject: Re: NFS root manipulation without being superuser?
>
>
>
> Brian Waite writes:
> > you could export the fs from the dev host as
> no_root_squash an insecure
> > for example
> > /home *(rw,insecure,no_root_squash)
> >
> > That will allow the embedded host to modify files on
> the NFS filesystem as
> > root. Does tha accomplish what you need?
>
> Thanks Brain for the reply. No, that is not really what
> I mean. I
> want to be able to manipulate/create/alter the target's root
> filesystem (exported from the development workstation) from the
> _development_ workstation. I want to be able to do so
> without having
> to change to superuser privleges on the development workstation.
>
> For example, say I export an NFS root filesystem to my
> target. This
> filesystem on my development machine is located within my home
> directory. For example:
>
> /home/me/target
> /home/me/target/bin
> /home/me/target/root
> /home/me/target/lib
> /home/me/target/dev
> ... you get the idea.
>
> Now, from my development workstation, as user "me", I
> would like to be
> able to install a program to the target's NFS root filesystem. I
> would like that program to appear as having root ownership to the
> target. For example, user "me" installs the program "foo" to:
>
> /home/me/target/bin/foo
>
> On the development machine this would look like:
> developmentt$ ls -l /home/me/target/bin/foo
> -rwxr-xr-x 1 me me 48 Nov 15 10:59 foo
>
> On the target machine this would look like:
> target$ ls -l /bin/foo
> -rwxr-xr-x 1 root root 48 Nov 15 10:59 foo
>
> I guess maybe I thought there might be a way to do some
> sort of NFS
> user/group mapping so that you could "trick" the target
> into thinking
> files were owned by root whereas on the development
> machine they are
> in reality owned by user "me". Or some sort of tricks
> that could be
> played using fakeroot and those kinds of programs.
>
> I guess what I really want is a way, from my development
> workstation,
> to have the "power" of root to manipulate the target's filesystem
> (i.e., the files under /home/me/target directory) WITHOUT
> having the
> "power" to screw up the development workstation's system
> files. Does
> this make sense to anyone or is the caffeine affecting my
> thinking?
>
> --
> Jeff Kowing
> jeffrey.d.kowing@nasa•gov
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-11-16 0:31 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-15 16:37 NFS root manipulation without being superuser? Jeff Kowing
2002-11-15 18:48 ` Brian Waite
2002-11-15 19:58 ` Jeff Kowing
2002-11-15 20:24 ` Chris Hallinan
[not found] <0060C09C.C21188@nasa.gov>
2002-11-15 20:16 ` Jerry Van Baren
2002-11-15 21:51 ` William A. Gatliff
2002-11-15 22:42 ` Jerry Van Baren
-- strict thread matches above, loose matches on Subject: below --
2002-11-16 0:31 Rod Boyce
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox