Menu
▾
▴
securenfs-devel — Developer's Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(42) |
Nov
|
Dec
|
|---|
|
From: Nathan Y. <na...@yo...> - 2002-10-12 20:03:57
|
> Well, forums are nice because there is better threading support. I'd > suggest a private forum on sourceforge, if we do it on shemp we > might as well use phorum that I have already set up (rather than > installing YAF (Yet Another Forum). I'd actually rather use a forum > because I don't like using webmail from off campus (and I don't want > to send my IMAP password in plain text!) . I agree ;-) I will look at setting up the forums on sourceforge, if they don't seem too nice we can use the phorum stuff on shemp (assuming we can create a private forum). We can then use this list for announcements etc, but maintain discussions on the forum (where threads will ease the burden for sure). > > 2. Anyone want to volunteer to get the framed snfsd module compiling > > (resolve circular .h stuff, correct declaration of the STL stuff, etc) ? > > :-) Its been too long since I have dealt with such issues so I am slowly > > becoming familiar again. > > > I can do this. I'll look at it today. I've had lots of practice > lately. Cool - thanks. |
|
From: David W. <wo...@pl...> - 2002-10-12 20:03:40
|
I just committed a version of snfsd that compiles for me. Nate, check to make sure that this compiles in gcc 3.1. Just for future reference, make sure all .h files have multiple inclusion checks, for example for file foo.h: #ifndef FOO_H #define FOO_H ... all of the header file goes here ... #endif This avoids multiple inclusions of a single header file. Dave -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
|
From: David W. <wo...@pl...> - 2002-10-12 19:31:52
|
Nathan Yocom wrote: > 2 quick things: > > 1. Email lists are fine by me, but a topic oriented discussion forum may > be just as productive - what do you guys think? Myself, email is easiest > to manage, but we could do a private forum on sourceforge, or set one up > on shemp in the snfs.cs.plu.edu area... > Well, forums are nice because there is better threading support. I'd suggest a private forum on sourceforge, if we do it on shemp we might as well use phorum that I have already set up (rather than installing YAF (Yet Another Forum). I'd actually rather use a forum because I don't like using webmail from off campus (and I don't want to send my IMAP password in plain text!) . > 2. Anyone want to volunteer to get the framed snfsd module compiling > (resolve circular .h stuff, correct declaration of the STL stuff, etc) ? > :-) Its been too long since I have dealt with such issues so I am slowly > becoming familiar again. I can do this. I'll look at it today. I've had lots of practice lately. Dave > > Later! > Nate > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
|
From: Nathan Y. <na...@yo...> - 2002-10-12 19:25:30
|
2 quick things: 1. Email lists are fine by me, but a topic oriented discussion forum may be just as productive - what do you guys think? Myself, email is easiest to manage, but we could do a private forum on sourceforge, or set one up on shemp in the snfs.cs.plu.edu area... 2. Anyone want to volunteer to get the framed snfsd module compiling (resolve circular .h stuff, correct declaration of the STL stuff, etc) ? :-) Its been too long since I have dealt with such issues so I am slowly becoming familiar again. Later! Nate |
|
From: Nathan Y. <na...@yo...> - 2002-10-12 19:23:50
|
Doxygen is available here: www.doxygen.org or with "emerge doxygen" in Gentoo If you don't use gentoo linux, be sure to also get and install the Graphviz tools, as they are used to create class diagrams etc. The doxygen_config file included in the snfsd module is NOT tweaked, it is just a template provided by doxygen. At some point we should go through it and tweak it to give us what we like (and remove what we dont). Nate |
|
From: Nathan Y. <na...@yo...> - 2002-10-12 19:20:21
|
Okay, here is what I gather as far as a roadmap/todo list, feel free to bring up changes/ideas as I am just throwing it together based on our discussions to date: Version 0.0.0 ------------- Current -> Includes basic (not necessarily compiling) code framework and CVS module Version 0.0.1 ------------- Bryce: First Config class implementation (basic) Nate: Network class implementation (tested with thread-test module by Dave) Dave: First TokenCollection class implementation (basic), using STL map After version 0.0.1 is in CVS, we should be able to use thread-test to do some initial analysis of the thread design etc. I am guessing this is something we will all want to be involved in. I have not included 'assignments' of people->task for future revisions, as we can deal with that in the future, spreading out the work to where each of us feels most comfortable/has time etc... Version 0.0.2 ------------- Config class implementation (full) TokenCollection class implementation (full) Basic TokenHandler implementation Basic PAM (client side) module, connects to server, prints recieved token Version 0.0.3 ------------- Extend client PAM, reads Config, connects to server, puts token in /proc Basic client kernel module, creates /proc file for client PAM Version 0.0.4 ------------- Full TokenHandler implementation Full client PAM At this point then, we should have a snfsd server process that can read its config, listen/grant token requests, kick off threads (that do nothing for now). We should also have a client PAM module that can read its config, request and recieve tokens, and a client Kernel module that creates the appropriate /proc area. We can then re-evaluate where we are, review design and other decisions, and determine the best way to go forward again. Let me know what you think... this should give us plenty to do for the time being. I am going to get to work on the NetworkServer class so we can start doing some testing with threads etc.. Nate |
|
From: Nathan Y. <na...@yo...> - 2002-10-12 19:07:18
|
Okay, I shelled out the classes we discussed and imported them as modulename: snfsd in CVS on shemp. I also included a makefile (modeled after the one Dave used in his thread-test) and a doxygen_config file for running doxygen on the code (it creates html and latex docs in docs/). I havent tweaked anything though - so it doesnt even all compile ;-) I have no doubt but what there are #include issues (which we need to #ifdef out) etc. Anyway, its there now.. I am going to send another message after this one with a roadmap/todo list so look for that. Nate |
|
From: Nathan Y. <na...@yo...> - 2002-10-12 04:48:37
|
Sweet! I will take a look this weekend for sure. Also be on the lookout for a roadmap style document/todo once I have written all this class stuff up ;-) Nate David Wolff wrote: > > Hey folks, > > Well, this threading stuff is just too much fun!! I've added > a small project to cvs (on shemp) called thread-test. > Check it out and read through it. Basically it just creates > ten threads that do busy work (an empty loop) and then quits. > > I have created a thread superclass called SnfsThread. We should > be able to inherit from it whenever we want "thread-like" > behavior. > > Note, before you run it you may want to change the number of > iterations in the busy loop (in TestThread.cpp) because I > had to make it fairly large for my 2GHz machine. > > It works on Linux and Solaris, but on Solaris the threads do > not do any timesharing so we'll have to do some tuning. > > Hopefully, Nate, you can add some network stuff to get these > threads to model the server setup. > > Let me know what you think! > > dw > |
|
From: David W. <wo...@pl...> - 2002-10-12 00:51:05
|
Hey folks, Well, this threading stuff is just too much fun!! I've added a small project to cvs (on shemp) called thread-test. Check it out and read through it. Basically it just creates ten threads that do busy work (an empty loop) and then quits. I have created a thread superclass called SnfsThread. We should be able to inherit from it whenever we want "thread-like" behavior. Note, before you run it you may want to change the number of iterations in the busy loop (in TestThread.cpp) because I had to make it fairly large for my 2GHz machine. It works on Linux and Solaris, but on Solaris the threads do not do any timesharing so we'll have to do some tuning. Hopefully, Nate, you can add some network stuff to get these threads to model the server setup. Let me know what you think! dw -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
|
From: Bryce B. <boc...@pl...> - 2002-10-08 23:04:49
|
I should be able to make it too. See ya there. -Bryce Nathan Yocom wrote: > Sounds like a plan. > > David Wolff wrote: > >> >> Works for me. How about 4:00 PM this time? >> >> Dave >> >> >> Nathan Yocom wrote: >> >>> We should meet again to start outlining the data-structures and >>> class heirarchy etc of snfs. We should also start looking at >>> creating an infrastructure for testing - including testing of snfs >>> as well as developing "proof-of-concept" style code. >>> >>> Thursday good? Nate >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by:ThinkGeek >>> Welcome to geek heaven. >>> http://thinkgeek.com/sf >>> _______________________________________________ >>> securenfs-devel mailing list >>> sec...@li... >>> https://lists.sourceforge.net/lists/listinfo/securenfs-devel >> >> >> >> >> > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel |
|
From: Nathan Y. <na...@yo...> - 2002-10-08 21:45:10
|
Sounds like a plan. David Wolff wrote: > > Works for me. How about 4:00 PM this time? > > Dave > > > Nathan Yocom wrote: > >> We should meet again to start outlining the data-structures and class >> heirarchy etc of snfs. We should also start looking at creating an >> infrastructure for testing - including testing of snfs as well as >> developing "proof-of-concept" style code. >> >> Thursday good? Nate >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> securenfs-devel mailing list >> sec...@li... >> https://lists.sourceforge.net/lists/listinfo/securenfs-devel > > > > |
|
From: David W. <wo...@pl...> - 2002-10-08 21:30:38
|
Works for me. How about 4:00 PM this time? Dave Nathan Yocom wrote: > We should meet again to start outlining the data-structures and class > heirarchy etc of snfs. We should also start looking at creating an > infrastructure for testing - including testing of snfs as well as > developing "proof-of-concept" style code. > > Thursday good? Nate > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
|
From: Nathan Y. <na...@yo...> - 2002-10-08 01:44:08
|
We should meet again to start outlining the data-structures and class heirarchy etc of snfs. We should also start looking at creating an infrastructure for testing - including testing of snfs as well as developing "proof-of-concept" style code. Thursday good? Nate |
|
From: Nathan Y. <na...@yo...> - 2002-10-02 21:01:21
|
David Wolff wrote: > Quick question, what are we going to call the client? 'mount.snfs'? > > The server, I'm assuming will be called snfsd? Yup, and Yup ;-) Unless there are other ideas? These do seem to match the *nix convention. > I think we should also revisit the data structure for holding tokens, > IPs, and etc... on the server side. Oh yeah! Forgot hehe, lets put this at the top of the list. >> How would you all like to proceed? Should we meet again to do some >> of this? or is it well enough understood/discussed to allow for >> splitting it up and tackling it via email/individually? > > I think that we should probably write a test of our threading model > first. If there is a problem with that design, then we may need to > modify things. Good thought. > As far as shelling out the code, I suggest that we get together to > do this. Each thing is interconnected so it would be difficult to > assign jobs, unless someone wants to come up with a design for all > three! :) Ditto, when should we meet? Is thursday still a good day for everyone? I think going over the datastructure, then a rough sketch of the server classes (at least pertaining to the threads) would be a good idea. Then we can put together a sample of the thread code and see how it works through simulation. Nate |
|
From: David W. <wo...@pl...> - 2002-10-02 19:53:46
|
> I think it makes sense to attack the mount, PAM, and server sections > first, before getting into the actual filesystem stuff so, Quick question, what are we going to call the client? 'mount.snfs'? The server, I'm assuming will be called snfsd? > Next few things to do: > - "shell" out classes and methods for the server > - "shell" out pam module (in accordance with PAM interface) > - "shell" out mount code - I am envisioning this as simply a > userlevel interface to the pam module that will handle per-user mount > requests as we discussed etc > - Test cases - put together a test case including a server that > manages tokens, and a client (for now at the user-level) that imitates > filesystem requests. We can use this to get statistics on load, > timings, etc, as well as provide the framework for the statistics > portion of the server. Sounds good. I think we should also revisit the data structure for holding tokens, IPs, and etc... on the server side. > > How would you all like to proceed? Should we meet again to do some of > this? or is it well enough understood/discussed to allow for splitting > it up and tackling it via email/individually? I think that we should probably write a test of our threading model first. If there is a problem with that design, then we may need to modify things. As far as shelling out the code, I suggest that we get together to do this. Each thing is interconnected so it would be difficult to assign jobs, unless someone wants to come up with a design for all three! :) Dave -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
|
From: Nathan Y. <na...@yo...> - 2002-10-02 19:37:19
|
Okay, so we have example config files that I believe work for us, at
least insofar as to further the design of the project... anyway, that
brings us to:
I think it makes sense to attack the mount, PAM, and server sections
first, before getting into the actual filesystem stuff so, the way I see
it (throw in other ideas/comments as you see fit of course):
Next few things to do:
- "shell" out classes and methods for the server
- "shell" out pam module (in accordance with PAM interface)
- "shell" out mount code - I am envisioning this as simply a
userlevel interface to the pam module that will handle per-user mount
requests as we discussed etc
- Test cases - put together a test case including a server that
manages tokens, and a client (for now at the user-level) that imitates
filesystem requests. We can use this to get statistics on load,
timings, etc, as well as provide the framework for the statistics
portion of the server.
How would you all like to proceed? Should we meet again to do some of
this? or is it well enough understood/discussed to allow for splitting
it up and tackling it via email/individually?
Nate
|
|
From: Nathan Y. <na...@yo...> - 2002-10-02 19:27:19
|
The following are the server and client example configs as provided by
David prior to creation of the mailing list:
========= SERVER ============
<?xml verion="1.0" standalone="yes" encoding="ISO-8859-1"?>
<snfsd-config version="0.1">
<pam-port>112</pam-port>
<snfsd-port>113</snfsd-port>
<log level="3"/>
<threads min="3" max="255"/>
<export dir="/home/users">
<allow>
<host addr="joe.schmoe.net" root-squash="yes">
<user id="joes"/>
<user id="sue"/>
<user id="fran"/>
</host>
<host addr="securenfs.sourceforge.net" root-squash="no>
<user id="*"/>
</host>
</allow>
<deny>
<host addr="*">
<user id="*"/>
</host>
</deny>
</export>
</snfsd-config>
========= CLIENT ============
<?xml version="1.0" standalone="yes" encoding="ISO-8859-1"?>
<mount.snfs-config version="0.1">
<server-port-pam>112</server-port-pam>
<server-port-snfs>113</server-port-snfs>
<mount-point local="/home/users" remote="server.host.com:/export/users">
<allow>
<user localid="dave" remoteid="dwolff"/>
<user localid="nate" remoteid="nyocom"/>
<group localid="staff" remoteid="users"/>
<user-nologin localid="apache" remoteid="apache" ssl-key="AF4BC8739"/>
<user-nologin localid="mysql" remoteid="mysql" ssl-key="C312AFCBE"/>
</allow>
<deny>
<user localid="*"/>
</deny>
</mount-point>
<mount-point local="*" remote="server.host.com:/export/web">
<allow>
<user localid="*" remoteid="internet"/>
</allow>
</mount-point>
</mount.snfs-config>
|
|
From: David W. <wo...@pl...> - 2002-09-29 23:47:47
|
Nathan Yocom wrote: > David Wolff wrote: > >>> Good question. Other than making sure we invalidate the token when >>> there are no more connections as a particular user, I can't think of >>> issues either way. It could be we actually hand't decided that yet >>> ;-) If we write something like: >>> uid:token:mnt_pt >>> to the /proc/ system, then we could almost just say in the pam module >>> "if uid exists in /proc, dont re-write the uid:token, just verify the >>> username and password and immediatley invalidate the token from the >>> server" - So the server would respond to the second login with a >>> token, that token would be invalidated, and the client would use the >>> existing token for further communication. >>> >> >> Couldn't the server just respond with the first token? > > > Makes sense. We could have the server maintain a count (ala counted > spinlocks) on the token and simply increment for requests originating > from the same host:username:password and decrement for every invalidate > command from host:username - when count == 0 then we remove the token > from the list. > > ? > Yep. Just what I was thinking. That avoids the messy invalidation step. Dave -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
|
From: Nathan Y. <na...@yo...> - 2002-09-29 23:42:22
|
David Wolff wrote: >> Good question. Other than making sure we invalidate the token when >> there are no more connections as a particular user, I can't think of >> issues either way. It could be we actually hand't decided that yet >> ;-) If we write something like: >> uid:token:mnt_pt >> to the /proc/ system, then we could almost just say in the pam module >> "if uid exists in /proc, dont re-write the uid:token, just verify the >> username and password and immediatley invalidate the token from the >> server" - So the server would respond to the second login with a >> token, that token would be invalidated, and the client would use the >> existing token for further communication. >> > > Couldn't the server just respond with the first token? Makes sense. We could have the server maintain a count (ala counted spinlocks) on the token and simply increment for requests originating from the same host:username:password and decrement for every invalidate command from host:username - when count == 0 then we remove the token from the list. ? |
|
From: David W. <wo...@pl...> - 2002-09-29 23:36:32
|
Nathan Yocom wrote: > Dave Wolff Wrote: > ============== > Which brings up another point. Say localUserA logs in and gets a token > for remoteUserA. Then localUserB logs in and is mapped to the > same remoteUserA. localUserB should then need to provide the > password for remoteUserA, and once authenticated would get a seperate > token. Now, the server doesn't know the difference between localUserA > and localUserB, he doesn't need to. So should we have two different > tokens or just a single token shared by both? > > ============ > Good question. Other than making sure we invalidate the token when > there are no more connections as a particular user, I can't think of > issues either way. It could be we actually hand't decided that yet ;-) > If we write something like: > uid:token:mnt_pt > to the /proc/ system, then we could almost just say in the pam module > "if uid exists in /proc, dont re-write the uid:token, just verify the > username and password and immediatley invalidate the token from the > server" - So the server would respond to the second login with a token, > that token would be invalidated, and the client would use the existing > token for further communication. > Couldn't the server just respond with the first token? Dave -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
|
From: Nathan Y. <na...@yo...> - 2002-09-29 23:17:49
|
Dave Wolff Wrote:
==============
Which brings up another point. Say localUserA logs in and gets a token
for remoteUserA. Then localUserB logs in and is mapped to the
same remoteUserA. localUserB should then need to provide the
password for remoteUserA, and once authenticated would get a seperate
token. Now, the server doesn't know the difference between localUserA
and localUserB, he doesn't need to. So should we have two different
tokens or just a single token shared by both?
============
Good question. Other than making sure we invalidate the token when
there are no more connections as a particular user, I can't think of
issues either way. It could be we actually hand't decided that yet ;-)
If we write something like:
uid:token:mnt_pt
to the /proc/ system, then we could almost just say in the pam module
"if uid exists in /proc, dont re-write the uid:token, just verify the
username and password and immediatley invalidate the token from the
server" - So the server would respond to the second login with a token,
that token would be invalidated, and the client would use the existing
token for further communication.
Nate
|
|
From: Nathan Y. <na...@yo...> - 2002-09-29 23:13:35
|
David Wolff wrote: > Nathan Yocom wrote: > >>> Actually, I was thinking that we could do this on the client side. >>> For example: >>> >>> <user localid="*" remoteid="username"/> >>> >>> instead of adding the map option. >> >> >> >> >> Thats what I am wondering - could it make sense to have it on both >> sides? That way, an administrator could restrict all access from a >> certain machine to a particular user account - without having to >> trust the client machine to configure it. > > > Well, from a useability standpoint, that might be kind of confusing. > A client may set up one mapping (local user to remote user), and > the server would make another mapping. Perhaps it makes the most > sense to not allow the server to do any user/group mappings at all. > It only knows that the client has permissions (a token) to connect > as a certain user. True. I guess I am just a fan of "when in doubt make it an option". Perhaps we should simply have the server do no mapping what so ever in initial revisions. In the future, should it become a requested feature, or if we come across a need, we can always add it in (versus doing the work and it never being used). I made your other question a new thread - help keep things organized. > P.S. When did you get your own domain (yocom.org)? ;-) Well, my @plu.edu will only last so long after December, and I refuse to use hotmail. So i did some looking, I wanted yo.com but it was taken, so I got yocom.org, threw up a website and started using it for email. I do hosting through www.phpwebhosting.com $10 a mth and pretty much unlimited features/use. Nate |
|
From: David W. <wo...@pl...> - 2002-09-29 22:54:41
|
Nathan Yocom wrote: >> Actually, I was thinking that we could do this on the client side. >> For example: >> >> <user localid="*" remoteid="username"/> >> >> instead of adding the map option. > > > > Thats what I am wondering - could it make sense to have it on both > sides? That way, an administrator could restrict all access from a > certain machine to a particular user account - without having to trust > the client machine to configure it. > Well, from a useability standpoint, that might be kind of confusing. A client may set up one mapping (local user to remote user), and the server would make another mapping. Perhaps it makes the most sense to not allow the server to do any user/group mappings at all. It only knows that the client has permissions (a token) to connect as a certain user. Which brings up another point. Say localUserA logs in and gets a token for remoteUserA. Then localUserB logs in and is mapped to the same remoteUserA. localUserB should then need to provide the password for remoteUserA, and once authenticated would get a seperate token. Now, the server doesn't know the difference between localUserA and localUserB, he doesn't need to. So should we have two different tokens or just a single token shared by both? Dave P.S. When did you get your own domain (yocom.org)? -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
|
From: Nathan Y. <na...@yo...> - 2002-09-29 22:43:37
|
Just a test message to the securenfs-devel list ;-) That and having this message allows me to setup my mail filters hehe Later! Nate |
