[9fans] remove files in /srv

[9fans] remove files in /srv

[YAMANASHI Takeshi]

Hi,

Anyone can replace files in /srv.  Bad things won't
happen if /srv/boot has been replaced by a malicious user?

Therefore, how about changing '#s' so that only file owner
or host owner can remove the file?
-- 

Re: [9fans] remove files in /srv

[arisawa]

>Anyone can replace files in /srv.  Bad things won't
>happen if /srv/boot has been replaced by a malicious user?
Try:
term% cd /srv
term% ls -ld /srv
d-r-xr-xr-x s 0 arisawa arisawa 0 Oct 26 20:44 /srv
term% ls -l
--rw-rw-rw- s 0 arisawa arisawa 0 Oct 26 20:44 boot
--rw-rw-rw- s 0 arisawa arisawa 0 Oct 26 20:44 cs
--rw-rw-rw- s 0 arisawa arisawa 0 Oct 26 20:44 dns
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 dos
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 f
--rw-rw-rw- s 0 arisawa arisawa 0 Oct 26 20:44 factotum
--rw-rw-rw- s 0 arisawa arisawa 0 Oct 26 20:44 fossil
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 fscons
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 nfsserver.chat
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 pc
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 plumb.arisawa.199
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 portmapper.chat
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 rio.arisawa.44
--rw------- s 0 arisawa arisawa 0 Oct 26 20:44 riowctl.arisawa.44
term% su alice
su# rm boot
rm: boot: permission denied
su# echo bla | /srv/boot
/srv/boot: permission denied
su# cp fossil boot
cp: can't create boot: srv file already exists
su# 

Kenji Arisawa
.

Re: [9fans] remove files in /srv

[Russ Cox]

 > Anyone can replace files in /srv.  Bad things won't
> happen if /srv/boot has been replaced by a malicious user?

#s/boot is explicitly unremovable.

> Therefore, how about changing '#s' so that only file owner
> or host owner can remove the file?

This won't work well.  9fs alice creates /srv/alice as the user
who runs it, but if the connection is lost and someone else
runs 9fs alice, then they need permission to remove it and
replace it. 

It's not at all clear what the right answer is.  The users have
to trust themselves in /srv.

Russ

Re: [9fans] remove files in /srv

[YAMANASHI Takeshi]

On Tue Feb  1 12:21:37 JST 2005, arisawa@ar.aichi-u.ac.jp wrote:
> >Anyone can replace files in /srv.  Bad things won't
> >happen if /srv/boot has been replaced by a malicious user?
 :
> su# rm boot
> rm: boot: permission denied

oops.  you can surely remove /srv/dns though.
what's the difference between boot and dns...?

I got it: #s is doing a special treatment for boot in
/sys/src/9/port/devsrv.c:/^srvremove .
	if(strcmp(sp->name, "boot") == 0)
		error(Eperm);

I'd rather have #s only removable by hostowner/file owner instead.
Would this change break something?
-- 

Re: [9fans] remove files in /srv

[arisawa]

>oops.  you can surely remove /srv/dns though.
>what's the difference between boot and dns...?

Permission bit of files in /srv/* is only formal, I think.
The meaning of the bit follows by the service program, not OS.
Service program can do anything what ever the bit is.

Kenji Arisawa

Re: [9fans] remove files in /srv

[Russ Cox]

> Permission bit of files in /srv/* is only formal, I think.
> The meaning of the bit follows by the service program, not OS.
> Service program can do anything what ever the bit is.

That's not true -- the bits are checked when the file is opened.
The real solution is to put directories in /srv and have a common
directory and personal directories.  But instead I made a smaller
change and tightened up what can be removed. 

Russ

Re: [9fans] remove files in /srv

[rog]

> The real solution is to put directories in /srv and have a common
> directory and personal directories.  But instead I made a smaller
> change and tightened up what can be removed.

i've sometimes wondered whether it might be worth having the
capability to have a non-shared /srv; e.g.  #snew gives a new, clean
instance of #s owned by the current user.  it would be possible to
move services between old and new by opening a file in the old #s and
writing the fd to the new one.  it would also be possible to access the
globally shared #s, but perhaps only the hostowner could post names
there.

that way, there's no clash of service names when people cpu in;
easier to implement than directories, too.
then again #s is also the source of lots of useful hacks.

just a thought.

Re: [9fans] remove files in /srv

[Bruce Ellis]

later inferno's #s has all the requested properties
(the #s in VN inferno is different).

if a user binds '#s' he gets a new empty one.  a named srv, e.g.
#sauth, is shared and a rebind is possible.  permissions and
lots of details are handled differently.

brucee

Re: [9fans] remove files in /srv

[Charles Forsyth]

>>(the #s in VN inferno is different).

no it's not!

>>if a user binds '#s' he gets a new empty one.  a named srv, e.g.
>>#sauth, is shared and a rebind is possible.  permissions and
>>lots of details are handled differently.

in fact, i was going to post something almost word-for-word!

Re: [9fans] remove files in /srv

[YAMANASHI Takeshi]

> This won't work well.  9fs alice creates /srv/alice as the user
> who runs it, but if the connection is lost and someone else
> runs 9fs alice, then they need permission to remove it and
> replace it. 

They can post a new connection under another name like
/srv/alice.username, can't they?

There are many other important services now in /srv to trust users.
I'm concerned for /srv/^(fossil fscons cs dns factotum) especially.
# boot is excluded because of the special treatment
-- 

Re: [9fans] remove files in /srv

[geoff]

[-- Attachment #1: Type: text/plain, Size: 111 bytes --]

Would it make sense for cs to maintain the posted connections in /srv?
Then only the hostowner has to do so.

[-- Attachment #2: Type: message/rfc822, Size: 3124 bytes --]

From: YAMANASHI Takeshi <9.nashi@gmail.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] remove files in /srv
Date: Tue, 1 Feb 2005 13:05:59 +0900
Message-ID: <c1665724bd566308f2588db2f6afafbf@orthanc.cc.titech.ac.jp>

> This won't work well.  9fs alice creates /srv/alice as the user
> who runs it, but if the connection is lost and someone else
> runs 9fs alice, then they need permission to remove it and
> replace it. 

They can post a new connection under another name like
/srv/alice.username, can't they?

There are many other important services now in /srv to trust users.
I'm concerned for /srv/^(fossil fscons cs dns factotum) especially.
# boot is excluded because of the special treatment
--