Re: Problem with permissions

Re: Problem with permissions

[Stas Sergeev]

Hello.

Stian Sletner wrote:
> I have a problem running DOSEMU in privileged mode.
How? "dosemu -s" ?

> kernel 2.6.12-1.1398_FC4.
I bet this is the culprit. RH is
known to apply the different security
patches that break dosemu, might be
one of such cases I think. Try fresh
kernel.

Re: Problem with permissions

[Stian Sletner]

* At 2005-08-09T21:20+0400, Stas Sergeev wrote:
: 
| How? "dosemu -s" ?

Tried both -s/sudo and setuid.

| >kernel 2.6.12-1.1398_FC4.
| I bet this is the culprit. RH is
| known to apply the different security
| patches that break dosemu, might be
| one of such cases I think. Try fresh
| kernel.

Ugh.  Well, I've ran Red Hat and Fedora forever and haven't really had
any problems of this sort before, I think.  Also, I have completely
disabled SELinux.  Thanks though.  I'll see about compiling a fresh one
some rainy day...

-- 
Stian Sletner

Problem with permissions

[Stian Sletner]

Hi.

I have a problem running DOSEMU in privileged mode.  It fails to open
/proc/self/*, so when starting doom it bombs out with:

ERROR: can't open /proc/self/maps
ERROR: Unable to allocate DPMI memory pool of size 0x1405000 at address 0x10000000

strace shows that it seems to setuid from root to my user before trying
to open these, maybe that's the problem?

20814 open("/proc/self/maps", O_RDONLY) = -1 EACCES (Permission denied)

I also noticed a lot of this stuff:

20814 vm86(0x1, 0x81a44e0, 0x64, 0x10000, 0) = -1 ENOSYS (Function not implemented)

But I don't know if that's a problem.

Thanks.

-- 
Stian Sletner

Re: Problem with permissions

[Stian Sletner]

As always, I forget the important stuff.

DOSEMU 1.3.2, Fedora Core 4, kernel 2.6.12-1.1398_FC4.

-- 
Stian Sletner

Problem with permissions

[David Shirley]

Hi All,

We have a NFSV3 server (UDP) and NFSV3 clients. Now
when the permissions on a file are say rwx-----x
ie world executable, then none owners and non group
members can read the file as well as execute it?

This shouldn't be the case?

Are there any switches or anything on the server that
I need to configure?

Cheers
Dave


/-----------------------------------
David Shirley
System's Administrator
Computer Science - Curtin University
(08) 9266 2986
-----------------------------------/


_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Problem with permissions

[Neil Brown]

On Thursday April 18, dave@cs.curtin.edu.au wrote:
> Hi All,
> 
> We have a NFSV3 server (UDP) and NFSV3 clients. Now
> when the permissions on a file are say rwx-----x
> ie world executable, then none owners and non group
> members can read the file as well as execute it?
> 
> This shouldn't be the case?
> 
> Are there any switches or anything on the server that
> I need to configure?
> 

I believe that this is a client issue (though it could possibly be a
server issue).

The server has to allow the client computer to read such a file so
that it can then execute it.  However the client computer should
restrict client applications to only using "exec" on the file, not
"open". 

When an application asks for an open(READ), the client should send an
ACCESS3 request to the server asking if that user has READ access.
The server will say "no" (at least the code looks like it should) and
the client should honour that.

What client OS are you using?
I seem to recall that there was a time when the Linux NFS client
didn't use ACCESS requests, but I think that has been fixed (but Trond
could say for sure).

It is all rather academic really.  If you want to read a file that is
executable but not readable, you just execute it under ptrace control
and suck out whatever you want from the process.


NeilBrown

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Problem with permissions

[Trond Myklebust]

>>>>> " " == Neil Brown <neilb@cse.unsw.edu.au> writes:

     > The server has to allow the client computer to read such a file
     > so that it can then execute it.  However the client computer
     > should restrict client applications to only using "exec" on the
     > file, not "open".

        mmap(/proc/<pid>/mem);

There isn't really a good way to restrict an application to only exec
the file. I believe you will find more reasons why Al & Linus have
refused to implement this if you trawl through the l-k archives.

     > What client OS are you using?  I seem to recall that there was
     > a time when the Linux NFS client didn't use ACCESS requests,
     > but I think that has been fixed (but Trond could say for sure).

ACCESS is unfortunately not yet fully implemented in any of the
existing Linux kernels. I still need to work on a good way to cache
the results.
At the moment we only check in order to try to overturn a false
negative on the permissions. Here we are talking about a false
positive.

Cheers,
  Trond

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs