Bringing up NFS server on 64 bits

Bringing up NFS server on 64 bits

[Pavel Fedin]

 Hello! I'm back with some more news.

 Currently i am building and testing NFS Server for 64 bits. The following
was done so far:
- libtirpc package - fixed to always export svc_auth_none (see my previous
message);
- rpcgen package - successfully rebuilt and tested, works fine, no changes
required;
- nfs-server package - successfully rebuilt against libtirpc with patching.
Testing is to be done.
- rpcbind - ported to Cygwin. Testing is to be done.

 Obsolete sunrpc package is almost not needed, except public headers in
include/rpcsvc. The following subset of the is needed by rpcbind (here and
below i will refer to C code at
http://git.infradead.org/users/steved/rpcbind.git/blob/HEAD:/src/security.c)
:
--- cut ---
#include <rpcsvc/mount.h>
#include <rpcsvc/rquota.h>
#include <rpcsvc/nfs_prot.h>
#include <rpcsvc/yp.h>
#include <rpcsvc/ypclnt.h>
#include <rpcsvc/yppasswd.h>
--- cut ---
 6 files so far. To tell the truth i feel a bit bad about having to keep the
complete obsolete package just for 6 files.

 I noticed that mount.h and nfs_prot.h (together with .x from which they are
generated) are available in a fresh version inside nfs-server source code.
The only missing thing is copying them to /usr/include during installation,
which can be easily fixed.
 The rest are: rquota.h, yp.h, ypclnt.h and yppasswd.h. Their definitions
are used only by check_callit() function, which obviously has something to
do with security and forcibly denies some actions. There are several things
to be done with them and i'd like to discuss what's better:
 1. Keep original sunrpc package in extremely reduced form, containing only
include/rpcsvc directory (this is how my test build is done).
 2. Pick up this thing and make a new package out of it:
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/librpcsvc/
 3. Export NFS-related includes from nfs-server package (creating
nfs-server-devel), and #ifdef the rest out.

 Personally i like (3) most of all because it's the simplest thing to do and
it won't pollute Cygwin with packages with almost no purpose. After all, who
uses NIS nowadays ? The only thing that makes me feeling bad - what does
this code actually do ? Won't disabling NIS-related stuff hurt security ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bringing up NFS server on 64 bits

[Corinna Vinschen]

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

On Jan 10 17:35, Pavel Fedin wrote:
>  Hello! I'm back with some more news.
> 
>  Currently i am building and testing NFS Server for 64 bits. The following
> was done so far:
> - libtirpc package - fixed to always export svc_auth_none (see my previous
> message);
> - rpcgen package - successfully rebuilt and tested, works fine, no changes
> required;
> - nfs-server package - successfully rebuilt against libtirpc with patching.
> Testing is to be done.
> - rpcbind - ported to Cygwin. Testing is to be done.

Thanks for working on that.  It's highly appreciated.  Did you already
make yourself familiar with Cygwin package maintainance(*)?

>  Obsolete sunrpc package is almost not needed, except public headers in
> include/rpcsvc. The following subset of the is needed by rpcbind (here and
> below i will refer to C code at
> http://git.infradead.org/users/steved/rpcbind.git/blob/HEAD:/src/security.c)
> :
> --- cut ---
> #include <rpcsvc/mount.h>
> #include <rpcsvc/rquota.h>
> #include <rpcsvc/nfs_prot.h>
> #include <rpcsvc/yp.h>
> #include <rpcsvc/ypclnt.h>
> #include <rpcsvc/yppasswd.h>
> --- cut ---
>  6 files so far. To tell the truth i feel a bit bad about having to keep the
> complete obsolete package just for 6 files.
> 
>  I noticed that mount.h and nfs_prot.h (together with .x from which they are
> generated) are available in a fresh version inside nfs-server source code.
> The only missing thing is copying them to /usr/include during installation,
> which can be easily fixed.
>  The rest are: rquota.h, yp.h, ypclnt.h and yppasswd.h. Their definitions
> are used only by check_callit() function, which obviously has something to
> do with security and forcibly denies some actions. There are several things
> to be done with them and i'd like to discuss what's better:
>  1. Keep original sunrpc package in extremely reduced form, containing only
> include/rpcsvc directory (this is how my test build is done).
>  2. Pick up this thing and make a new package out of it:
> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/librpcsvc/
>  3. Export NFS-related includes from nfs-server package (creating
> nfs-server-devel), and #ifdef the rest out.
> 
>  Personally i like (3) most of all because it's the simplest thing to do and
> it won't pollute Cygwin with packages with almost no purpose. After all, who
> uses NIS nowadays ? The only thing that makes me feeling bad - what does
> this code actually do ? Won't disabling NIS-related stuff hurt security ?

(3) sounds right to me.  As for NIS, I don't think this is important,
especially not for the NFS server.  In theory the OS (Windows) decouples
the NFS server from having to look for NIS stuff by itself.  Account
info should be available via the OS (Cygwin) calls anyway and worse,
assuming the NFS server fetches info directly via NIS, the entire
user/group -> uid/gid -> SID mapping might be screwed up.


Corinna


(*) https://sourceware.org/cygwin/setup.html
    https://sourceware.org/cygwin-apps/package-upload.html


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: Bringing up NFS server on 64 bits

[Pavel Fedin]

 Hello!

> Thanks for working on that.  It's highly appreciated.  Did you already
> make yourself familiar with Cygwin package maintainance(*)?

 Yes, i did. However, perhaps you'll call me a bad guy, but the answer to the first question:

 * Do you have the time to maintain the package?

 is "sorry, but likely no". I happen to have time only episodically. What obligations does this put on me exactly ? For example, does this mean that i must keep the package up to date and sync up with the mainstream ?
 Actually i have come into this only because i sometimes need NFS server myself. I work with embedded Linux systems, and sometimes i boot them up over NFS.

> (3) sounds right to me.  As for NIS, I don't think this is important,
> especially not for the NFS server.  In theory the OS (Windows)
> decouples the NFS server from having to look for NIS stuff by itself.
> Account info should be available via the OS (Cygwin) calls anyway and
> worse, assuming the NFS server fetches info directly via NIS, the
> entire user/group -> uid/gid -> SID mapping might be screwed up.

 No, this doesn't have anything to do with NFS server at all. It's about rpcbind, transport-independent replacement for portmap.
 I have examined ONC docs on Oracle's web site and now i have a little clue about this magic code. portmapper has a capability to perform indirect calls. This means that instead of querying for port number and sending direct request to the program you want to talk with, you can ask portmapper to do this instead of you. This code forcibly disables indirect calls for some things which were considered too dangerous by the author. However it looks like the whole ONC RPC is a security nightmare by design.
 By the way, does anybody know who is the original author of this NFS server ? Where is upstream repository ? I failed to find one.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bringing up NFS server on 64 bits

[Corinna Vinschen]

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

On Jan 10 18:29, Pavel Fedin wrote:
>  Hello!
> 
> > Thanks for working on that.  It's highly appreciated.  Did you already
> > make yourself familiar with Cygwin package maintainance(*)?
> 
>  Yes, i did. However, perhaps you'll call me a bad guy, but the answer to the first question:
> 
>  * Do you have the time to maintain the package?
> 
>  is "sorry, but likely no".

We can't take the packages if you're not willing to maintain them.
We already have enough packages where the maintainers disappeared.

> I happen to have time only episodically. What obligations does this put on me exactly ? For example, does this mean that i must keep the package up to date and sync up with the mainstream ?

Not necessarily.  If the package is in a good shape, has no known
security issues, and works fine with the latest Cygwin, you're good.
Other than that, just keep an eye on the Cygwin ML if somebody reported
a problem with your packages and see if you can lend a hand, maybe.

This is a generic problem.  Maintaining packages does not actually cost
a lot of time, unless you're trying to stick to the bleeding edge or
try to maintain too many packages.  But people still shy away from that
without even trying.  That's pretty disappointing.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: Bringing up NFS server on 64 bits

[Pavel Fedin]

 Hello!

> Not necessarily.  If the package is in a good shape, has no known
> security issues, and works fine with the latest Cygwin, you're good.
> Other than that, just keep an eye on the Cygwin ML if somebody reported
> a problem with your packages and see if you can lend a hand, maybe.

 This doesn't sound too bad.

> This is a generic problem.  Maintaining packages does not actually cost
> a lot of time, unless you're trying to stick to the bleeding edge or
> try to maintain too many packages.  But people still shy away from that
> without even trying.  That's pretty disappointing.

 Ok, i will try to.
 So far:
 Packages to update: rpcgen, nfs-server
 New package: rpcbind

 Is rpcgen maintained or not ?

 And, nobody has answered the question. Who are original authors of this NFS server ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bringing up NFS server on 64 bits

[marco atzeri]

Il 1/13/2014 6:48 AM, Pavel Fedin ha scritto:
>   Hello!
>
>> Not necessarily.  If the package is in a good shape, has no known
>> security issues, and works fine with the latest Cygwin, you're good.
>> Other than that, just keep an eye on the Cygwin ML if somebody reported
>> a problem with your packages and see if you can lend a hand, maybe.
>
>   This doesn't sound too bad.
>
>> This is a generic problem.  Maintaining packages does not actually cost
>> a lot of time, unless you're trying to stick to the bleeding edge or
>> try to maintain too many packages.  But people still shy away from that
>> without even trying.  That's pretty disappointing.
>
>   Ok, i will try to.
>   So far:
>   Packages to update: rpcgen, nfs-server
>   New package: rpcbind
>
>   Is rpcgen maintained or not ?
>
>   And, nobody has answered the question. Who are original authors of this NFS server ?

http://cygwin.com/cygwin-pkg-maint

rpcgen                          Charles Wilson


"From: Robb, Sam <sam.robb <at> timesys.com>
Subject: nfs-server 2.2.47-2
Newsgroups: gmane.os.cygwin.announce
Date: 2003-11-07 22:36:10 GMT (10 years, 9 weeks, 3 days, 19 hours and 
51 minutes ago)

The nfs-server package is now available for experimentation."

>
> Kind regards,

Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bringing up NFS server on 64 bits

[marco atzeri]

Il 1/13/2014 8:33 AM, Pavel Fedin ha scritto:
>> http://cygwin.com/cygwin-pkg-maint
>>
>> rpcgen                          Charles Wilson
>
>   Where is he ? I have posted a message about small bug in libtirpc, he doesn't reply...
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>

he is around ;-)

http://cygwin.com/ml/cygwin/2013-12/authors.html

and I assume busy.

Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bringing up NFS server on 64 bits

[Corinna Vinschen]

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

On Jan 13 09:48, Pavel Fedin wrote:
>  Hello!
> 
> > Not necessarily.  If the package is in a good shape, has no known
> > security issues, and works fine with the latest Cygwin, you're good.
> > Other than that, just keep an eye on the Cygwin ML if somebody reported
> > a problem with your packages and see if you can lend a hand, maybe.
> 
>  This doesn't sound too bad.
> 
> > This is a generic problem.  Maintaining packages does not actually cost
> > a lot of time, unless you're trying to stick to the bleeding edge or
> > try to maintain too many packages.  But people still shy away from that
> > without even trying.  That's pretty disappointing.
> 
>  Ok, i will try to.

Thanks!

>  So far:
>  Packages to update: rpcgen, nfs-server
>  New package: rpcbind
> 
>  Is rpcgen maintained or not ?

Marco answered that.

>  And, nobody has answered the question. Who are original authors of this NFS server ?

SUN Microsystems, AFAIK.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]