Re: [9fans] remove files in /srv

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

[9fans] allocb question

[Tim Newsham]

I'm allocating a block that has special alignment requirements.
I'm doing the following:

         Block *bp;

         bp = iallocb(EthBufSz + 64);
         if(bp)
                 bp->rp = (uchar*)ROUNDUP((ulong)bp->rp, 64);
         return bp;

which seems to work, but feels a little dirty.  Is this
the right way to do this or is there another mechanism
I should be using?

Tim N.

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!