executable but not readable
Subsystems (2)
Hi alltogether,
(I'm sorry to bother you with this but I could not find any clues yet)
Szenario:
* a server exports shell scripts to clients with root_squash
* these scripts have -rwx-r-x--x (root:root) rights (executable but
not readable)
The clients are able to run these scripts with server kernel version 2.4.20. Now we switched the server to 2.4.25 and get "permission denied" on execution.
As far as I comprehend file permissions this should never have worked?
But nobody ever noticed as long as it worked and the guy in charge says: "This was always a feature on VMS." :-P
This assumption is confirmed by the fact that "su nobody -c /usr/local/sbin/mkclonediskremupdate" executed on the server does not work either.
Are these observations correct or am I missing something?
Sorry for the silly question.
Regards,
Christopher
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 to , 25/03/2004 klokka 13:00, skreiv Christopher Huhn:
Quoted 1 line
The clients are able to run these scripts with server kernel version 2.4.=
20.
Quoted 2 lines
Now we switched the server to 2.4.25 and get "permission denied" on=20 execution.
On page 99, RFC1813 states explicitly that
A similar problem has to do with paging in an executable program over the network. The operating system usually checks for execute permission before opening a file for demand paging, and then reads blocks from the open file. In a local UNIX file system, an executable file does not need read permission to execute (pagein). An NFS version 3 protocol server can not tell the difference between a normal file read (where the read permission bit is meaningful) and a demand pagein read (where the server should allow access to the executable file if the execute bit is set for that user or group or public). To make this work, the server allows reading of files if the uid given in the call has either execute or read permission on the file, through ownership, group membership or public access. Again, this departs from correct local file system semantics.
So if the server is denying read access in 2.4.25, then someone must have introduced a bug...
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi Trond,
thanks first for your prompt answer.
Quoted 12 lines · Trond Myklebust
På to , 25/03/2004 klokka 13:00, skreiv Christopher Huhn:
Quoted 4 lines
The clients are able to run these scripts with server kernel version 2.4.20. Now we switched the server to 2.4.25 and get "permission denied" on execution.
On page 99, RFC1813 states explicitly that
A similar problem has to do with paging in an executable program over the network.
The point is that I'm not talking about (ELF) executables but shell scripts!
IMHO in local semantics the shell interpreter cannot execute scripts the executor has not read permissions for (How should he without beeing setuid root?).
I made these tests with ls and a script ls.sh that simply calls ls :
-rwxr-x--x 1 root root 43784 Mar 18 2002 /bin/ls -rwxr-x--x 1 root root 30 Mar 26 10:20 /bin/ls.sh
nobody@client[2.4.25-gsi]# /bin/ls ... works ...
nobody@client[2.4.25-gsi]# /bin/ls.sh /bin/ls.sh: /bin/ls.sh: Permission denied
and on the server:
nobody@server[2.4.20]# /bin/ls ... works ...
nobody@server[2.4.20]# /bin/ls.sh /bin/ls.sh: /bin/ls.sh: Permission denied
Quoted 4 lines
To make this work, the server allows
reading of files if the uid given in the call has either execute or read permission on the file.
This happens over NFS:
root@client[2.4.25-gsi]# /nfs/mount/2.4.20/ls ...works ...
root@client[2.4.25-gsi]# /nfs/mount/2.4.20/ls.sh ... works ...
root@client[2.4.25-gsi]# cat /nfs/mount/2.4.20/ls.sh ... works (so no security improvements by setting sensitive scripts --x over nfs ) ...
*but*
root@client[2.4.25-gsi]# /nfs/mount/2.4.25/ls ... works ...
root@client[2.4.25-gsi]# /nfs/mount/2.4.25/ls.sh /nfs/mount/2.4.25/ls.sh: /nfs/mount/2.4.25/ls.sh: Permission denied
and to complete this:
root@client[2.4.20]# /nfs/mount/2.4.25/ls ... works ...
root@client[2.4.20]# /nfs/mount/2.4.25/ls.sh /nfs/mount/2.4.25/ls.sh: /nfs/mount/2.4.25/ls.sh: Permission denied
Btw: Nor ls neither ls.sh can be cat'ed in these constellations.
Quoted 4 lines
Again, this departs from
correct local file system semantics.
With 2.4.25 it seems to comply with the local semantics rather than RFC1813.
Quoted 4 lines
So if the server is denying read access in 2.4.25, then someone must have introduced a bug...
That's what it seems, even though I like it the way it is now :-)
These are our specs:
Vanilla kernels 2.4.20 with
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_TCP is not set
# CONFIG_NCPFS_NFS_NS is not set
and 2.4.25 with
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_TCP=y
# CONFIG_NCPFS_NFS_NS is not set
The exports are rw,root_squash
The mount options are rw,sync,v3,rsize=8192,wsize=8192,hard,intr,udp,lock
We are using the nfs-common and nfs-kernel-server debian packages version 1.0-2woody1.
Regards,
Christopher
P=E5 fr , 26/03/2004 klokka 05:48, skreiv Christopher Huhn:
Quoted 5 lines
The point is that I'm not talking about (ELF) executables but shell scripts!=20
IMHO in local semantics the shell interpreter cannot execute scripts the executor has not read permissions for (How should he without beeing setuid root?).
That is irrelevant: the server knows nothing about the existence of shell scripts. The point in the RFC is that the server should be looking at both the "executable" and the "read" bits when deciding whether or not to grant read access to the client.
In NFSv3, the ACCESS call should then be used to decide whether or not the client is allowed to open the file for execution (and for reading if that is required). Unfortunately ACCESS is not implemented in the stock Linux 2.4.x kernel.
Otherwise the client can only look at the mode bits in order to try to make the same decision. Of course that will fail to work properly anyway if the server has a different uid/gid mapping scheme to the client.
However if you really want to prevent OTHER+GROUP from reading and executing your shell scripts, then "chmod 500 /bin/ls.sh" is your simplest solution. That does the same thing on both the local and remote filesystems.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 5 lines · Trond Myklebust
In NFSv3, the ACCESS call should then be used to decide whether or not the client is allowed to open the file for execution (and for reading if that is required). Unfortunately ACCESS is not implemented in the stock Linux 2.4.x kernel.
So the kernel does its own permission checking on the client side for executables _knowing_ that it is going to execute the file but unfortunately the interpreter has to open the file by itself and that fails.
But from a different perspective:
Being able to create a (non-setuid) executable which cannot be read for security reasons looks very weak to me unless of course it is not possible to let it dump core, strace (ptrace) it, open /proc/... files etc. But is that all actually the case in 2.6?
Signature · 11 lines
Frank ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ NFS maillist - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 lau , 27/03/2004 klokka 07:17, skreiv Frank van Maarseveen:
Quoted 4 lines · Trond Myklebust
Quoted 3 lines
=20
In NFSv3, the ACCESS call should then be used to decide whether or not the client is allowed to open the file for execution (and for reading i=
f
Quoted 7 lines
Quoted 2 lines
that is required). Unfortunately ACCESS is not implemented in the stock Linux 2.4.x kernel.
=20
So the kernel does its own permission checking on the client side for executables _knowing_ that it is going to execute the file but unfortunately the interpreter has to open the file by itself and that fails.
No... The kernel should do permission checking for execute, then opens the file for reading (overriding the read permissions since this is the kernel).
Unfortunately, the server is broken, and failing to follow RFC1813 when it comes to allowing reads on executables.
Quoted 6 lines
But from a different perspective:
=20
Being able to create a (non-setuid) executable which cannot be read for security reasons looks very weak to me unless of course it is not possible to let it dump core, strace (ptrace) it, open/proc/... files etc. But is that all actually the case in 2.6?
Sounds like a good test of the 2.6 VFS. Have you tried it?
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 5 lines · Trond Myklebust
P=E5 lau , 27/03/2004 klokka 07:17, skreiv Frank van Maarseveen:
Quoted 4 lines · Trond Myklebust
Quoted 3 lines
=20
In NFSv3, the ACCESS call should then be used to decide whether or not the client is allowed to open the file for execution (and for reading=
if
Quoted 1 line
Quoted 1 line
Quoted 1 line
that is required). Unfortunately ACCESS is not implemented in the sto=
ck
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Linux 2.4.x kernel.
=20
So the kernel does its own permission checking on the client side for executables _knowing_ that it is going to execute the file but unfortunately the interpreter has to open the file by itself and that fails.
Quoted 7 lines
=20
No... The kernel should do permission checking for execute, then opens the file for reading (overriding the read permissions since this is the kernel).
=20
Unfortunately, the server is broken, and failing to follow RFC1813 when it comes to allowing reads on executables.
I don't understand this. The server doesn't see the difference between a read for "read" purposes and a read for "execute" purposes IIRC. How can the server then be broken?
Quoted 9 lines
=20
Quoted 6 lines
But from a different perspective:
=20
Being able to create a (non-setuid) executable which cannot be read for security reasons looks very weak to me unless of course it is not possible to let it dump core, strace (ptrace) it, open/proc/... files etc. But is that all actually the case in 2.6?=20
Sounds like a good test of the 2.6 VFS. Have you tried it?
um, no, that's why I asked it. If security fails here and if it's insolvable then it is a reason to drop the client side ACCESS check in 2.6 for read versus execute permission because it wouldn't buy you anything.
--=20
Frank
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 su , 28/03/2004 klokka 18:59, skreiv Frank van Maarseveen:
Quoted 7 lines
Quoted 3 lines
=20
Unfortunately, the server is broken, and failing to follow RFC1813 when it comes to allowing reads on executables.=20
I don't understand this. The server doesn't see the difference between a read for "read" purposes and a read for "execute" purposes IIRC. How can the server then be broken?
Read the paragraph I quoted earlier in this thread from RFC1813. The server is supposed to allow READ if the executable bit is set.
The ACCESS call should, however, act exactly like the local sys_access(), and so should return an error if the user asks for READ permission.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi again,
Quoted 6 lines · Trond Myklebust
The point in the RFC is that the server should be looking at both the "executable" and the "read" bits when deciding whether or not to grant read access to the client.
...
Quoted 6 lines
However if you really want to prevent OTHER+GROUP from reading and executing your shell scripts, then "chmod 500
/bin/ls.sh" is your simplest solution. That does the same thing on both the local and remote filesystems.
I'm totally aware of the fact that this approach to enhance the security is dysfunctional and pretty lame [sigh]. Anyway, it was done like this in ancient days - and never worked but never did any harm either.
Now it's not working anymore and the only thing changed is the kernel.
So to get back to my initial question: *Is this a NFS bug?* Or has maybe something else changed in the kernel?
Regards,
Christopher