se-samba

se-samba

[Joshua Brindle]

A few of us talked about samba at a get together a few weeks ago and 
since it seems like we have a new ambition user on the list who is part 
of the samba-tng team I thought I'd bring this up.

Apparently Luke Kenneth Casson Leighton is part of the samba-tng team? 
(correct me if I'm wrong) So I'll lay out what we talked about for 
getting samba to support selinux in a meaningful way.

Basically the idea is that samba runs in it's own domain (ofcourse), but 
this domain has to be able to access/read/write files in other domains, 
particularly user domains. However we want the same enforcements over 
samba that a user would get on the local system, so the idea is to make 
samba use the userspace-avc library to do permission validation before 
it allows any access by the user. This would allow samba to access all 
user files which it has permission to, but rely on it to validate the 
connecting users permissions by passing the request to the userspace 
avc. This wouldn't be hard to implement but I'm curious to hear what 
someone who works on samba thinks of the idea..

Joshua Brindle

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

On Thu, May 20, 2004 at 01:42:20PM -0500, Joshua Brindle wrote:
> A few of us talked about samba at a get together a few weeks ago and 
> since it seems like we have a new ambition user on the list who is part 
> of the samba-tng team I thought I'd bring this up.
 
 hello.

> Apparently Luke Kenneth Casson Leighton is part of the samba-tng team? 
> (correct me if I'm wrong) 

 *sigh*.  yes, i am - an inactive member.  for a number of reasons.
 
 i tried installing samba recently with winbind, and when i discovered
 that it was no significantly further along from 2000, i had to dig
 a bit further.  after a few hours, i started to get very depressed,
 which lasted several days.  there were _really_ good reasons why
 i stopped working on samba.

 so, i know you didn't ask, but now you know a little about the
 effects of what happened in 2000.


 all that having been said, it is ironic that the intent of the samba tng
 project was to subdivide it at clear protocol boundaries, such as
 authentication points, NT services, and even at the LANMAN pipes.

 so, NT authentication is done in samrd, which is root-access-only
 over a unix domain socket.

 that sort of thing.

 there is quite a bit of sorting out still to do.


> So I'll lay out what we talked about for 
> getting samba to support selinux in a meaningful way.

 okay.

 i'll bite.

> Basically the idea is that samba runs in it's own domain (ofcourse), but 
> this domain has to be able to access/read/write files in other domains, 
> particularly user domains. However we want the same enforcements over 
> samba that a user would get on the local system, so the idea is to make 
> samba use the userspace-avc library to do permission validation before 
> it allows any access by the user. 

> This would allow samba to access all 
> user files which it has permission to, but rely on it to validate the 
> connecting users permissions by passing the request to the userspace 
> avc. This wouldn't be hard to implement but I'm curious to hear what 
> someone who works on samba thinks of the idea..
 

 in other words, you are being bitten by the same seteuid issue that is
 affecting famd.

 the thing is, you can't do userspace stuff like that without running
 into serious race conditions.

 samba has been _specifically_ designed to avoid race conditions and
 security issues.  andrew tridgell has absolutely zero respect for
 people that he deems to be a threat to him, but he is an extremely
 competent and experienced unix systems programmer [and from there
 unfortunately he believes that that competence and experience gives
 him authority in areas beyond his expertise].

 anyway.

 if i remember correctly, samba source code has quite good
 autoconf support and is capable of adapting to OSes that
 DON'T have seteuid.

 in other words, they use setuid.

 under such circumstances, the smbd daemon, when it attempts to gain
 root (at the end of a file access session), will exit.

 now, you _will_ get problems with this approach if your client
 attempts to use the same SMB session (which in smbd's design means
 using the same smbd process) for multiple user sessions.

 that means that if you use Citrix or other multi-session NT
 systems, and even in some other circumstances such as threaded
 DCE/RPC applications (spoolss printing being one of them),
 you end up with problems.

 why?  because the SMB protocol has the means for several separate
 user sessions to be multiplexed onto the same SMB connection
 (TCP connection or IPX/SPX connection.  although samba doesn't
 support IPX/SPX, the NetBIOS protocol does).

 the use of seteuid avoids these issues because inside the same
 smbd server, just before accessing a file, a user context switch
 is performed.
 
 so.

 you have hit upon a design flaw in samba.


 the solution is one which will actually dramatically improve samba
 in some unexpected ways, and it is a solution that has been deployed
 by other SMB server vendors (commercial ones).

 what you do is you split out the file handling from the SMB processing,
 into separate daemons.

 the design of the SMB protocol reflects, implicitly, its origins in:

 1) the INT 33 (or 21 or 10, i forget which) DOS disk access system
    "shoved" over-the-wire.

 2) a multithreaded server.

 by separating the SMB-processing from the file-accessing, you
 effectively end up with an easy opportunity to emulate
 multi-threading, and in the process a very very long-standing
 and obscure bug will be fixed [which can be demonstrated by running
 a multi-threaded benchmark test suite against a samba server].


 now, you _might_ be able to get away with writing a VFS plugin,
 or by subdiving the smbd source code so that the file-access bits
 of smbd are called (eventually) by the SMB-parsing bits of smbd.

 in fact, if i was going to do the work, that's where i would start,
 and once that was done, i would then add in a subdivision layer
 over, oh, say, unix domain sockets or shared memory communication.

 the two separate tasks (making all file access go via the VFS layer
 and then doing a daemon split at the same VFS interface) make very
 clear and very straightforward milestones.

 in fact, one possible simple implementation of the above is to
 write an SMB proxy VFS plugin which then accesses _another_ smb
 server, running on say port 8139 instead of 139.
  
 and i suspect that you may find that an SMB proxy VFS plugin
 already exists: if not, it'll only take a few days to write
 one using libsmb, or the same code used by smbclient.


 in this way, it becomes possible to run an smbd server without
 needing to know _anything_ about unix security model whatsoever,
 which communicates to a file server that is _specifically_ thunked
 on a per-process basis to deal with one user and its security
 context.

 
 and funnily enough it might actually result in a performance
 improvement, because a lot of user-context switching could be
 avoided.

 i did hear of someone porting samba to the linux kernel (!!!)
 in 1998 and they got a _dramatic_ performance of over 50%
 increase due to zero user-context switching.


 btw i am sorry you have to learn of the difficulties i had
 with the samba leaders, and also to hear about it here:
 the fault is mine, in that i was unable to moderate the
 way i presented ideas to them, and was unable to compromise
 effectively on design issues that i considered important.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

On Thu, May 20, 2004 at 09:10:32PM +0000, Luke Kenneth Casson Leighton wrote:

>  by separating the SMB-processing from the file-accessing, you
>  effectively end up with an easy opportunity to emulate
>  multi-threading, and in the process a very very long-standing
>  and obscure bug will be fixed [which can be demonstrated by running
>  a multi-threaded benchmark test suite against a samba server].
> 
> 
>  now, you _might_ be able to get away with writing a VFS plugin,
>  or by subdiving the smbd source code so that the file-access bits
>  of smbd are called (eventually) by the SMB-parsing bits of smbd.
> 
>  in fact, if i was going to do the work, that's where i would start,
>  and once that was done, i would then add in a subdivision layer
>  over, oh, say, unix domain sockets or shared memory communication.
> 
>  the two separate tasks (making all file access go via the VFS layer
>  and then doing a daemon split at the same VFS interface) make very
>  clear and very straightforward milestones.

 it looks like, in samba 3.0.2a, that all file access already goes
 through the VFS layer.

 therefore the only task needed is to network / unix-socket / 
 shmem the file access via the VFS layer.

 and to ensure that each user context is separated out.

 the function vfs_connect will be responsible for initiating
 a new connection of a new user context;

 the function vfs_disconnect will be responsible for closing
 that connection.

 the rest of the work is getting each of those vfs functions,
 of which unfortunately there are about forty or more, over
 a network.

 ironically, i'd actually recommend doing something like use DCE/RPC
 to do that :) :)

 but that doesn't help because freedce requires, thanks to IBM,
 quite a lot of work to do security contexts, and also, being
 threaded, it would require the same reworking as samba, and you're
 back where you started.

 so _some_ sort of RPC system is required, with an IDL compiler,
 to simplify the task of turning the VFS api into a networked
 one.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

On Thu, May 20, 2004 at 01:42:20PM -0500, Joshua Brindle wrote:
> A few of us talked about samba at a get together a few weeks ago and 
> since it seems like we have a new ambition user on the list who is part 
> of the samba-tng team I thought I'd bring this up.
> 
> Apparently Luke Kenneth Casson Leighton is part of the samba-tng team? 
> (correct me if I'm wrong) So I'll lay out what we talked about for 
> getting samba to support selinux in a meaningful way.
> 
> Basically the idea is that samba runs in it's own domain (ofcourse), but 
> this domain has to be able to access/read/write files in other domains, 
> particularly user domains. However we want the same enforcements over 
> samba that a user would get on the local system, so the idea is to make 
> samba use the userspace-avc library to do permission validation before 
> it allows any access by the user. This would allow samba to access all 
> user files which it has permission to, but rely on it to validate the 
> connecting users permissions by passing the request to the userspace 
> avc. This wouldn't be hard to implement but I'm curious to hear what 
> someone who works on samba thinks of the idea..

hi joshua,

okay, i've calmed down, now.  you weren't to know that even after
three years any mention of samba still hurts like hell.

anyway.  to recap, and also to alert people on the samba mailing lists:
SE/Linux does not provide an equivalent to the seteuid call, for security
reasons, and so a complete redesign / series of workarounds is required.


1) doing user-space avc library calls is fine IF you can guarantee
that the file system to which you are providing access is NOT
accessible by any means other than through se-samba [or that
any such access guarantees no race conditions].

i.e. you must, in effect, write your own userspace file system.

and you must guarantee that there are no race conditions etc.

as an example, given that DCE/DFS is an entirely userspace file server,
at least you know it can be done.

[and so is AFS, which is (oh it's a long story) sort-of DCE/DFS
 version 3 without the DCE/RPC bits and its own RPC system,
 gone off in a different direction, and then DCE/DFS got a
 rewrite and was called v4 etc etc. ]


as an example of what NOT to do, you MUST NOT create a file as root,
then chown it to the new user.  another process could, in the
meantime, access the file in between its creation and chowning,
and you're toast.

if you absolutely MUST do that, then at least create the file
as root in a guaranteed (for a given value of guaranteed of course)
isolated directory (on the same filesystem as the
target one), chown it and then mv it to the required location
[but it's still a bad idea].

... and that's just file create: what about everything else?  can
you guarantee that in between the last userspace avc call to
check access permissions that an NFS client, as root, hasn't
chown'd or recreated the same file?

hence you must ban all uncontrolled access and effectively you
need an isolated userspace file system.

_some_ commercial SMB fileserver companies _have_ actually done this!!


2) all file operations go through the SMB layer: you have to
provide a means to separate user-contexts on the same SMB TCP
connection, and the best - i.e. quickest way with a minimal
coding impact - way to do that is to run two smbd servers,
one proxying to the other and to write an SMB client VFS plugin
that multiplexes out the user-contexts received over the same
TCP connection.


3) an alternative is a rewrite to replace the SMB client VFS
plugin idea with a purpose built inter-process communication
system.


... although to be absolutely honest, when you already _have_
a dedicated IPC mechanism - it's called the SMB protocol - then
why go to all the trouble of writing another one?

arguments for doing your own VFS-dedicated IPC mechamism:

- the samba VFS layer isn't _exactly_ the SMB protocol in
other words you would have to hand-code every single function
in the

- samba's own smbclient code (libsmbclient) is unlikely
to be complete / an exact match for the known complexities
etc. heuristics etc. that have been built up over the last XX
man-years of work over the last X years of its life.

therefore, coding-wise, it's 1) pretty much automatic to auto-generate
an IPC mechanism based on the Samba VFS header files.  2) there
is a lot less to audit.  3) there is no need to hand-write all
fifty VFS layer functions, which you would have to do if you
went down the SMB client VFS layer route.

l.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

On Sat, May 29, 2004 at 09:51:53AM +0000, Luke Kenneth Casson Leighton wrote:

> > Basically the idea is that samba runs in it's own domain (ofcourse), but 
> > this domain has to be able to access/read/write files in other domains, 
> > particularly user domains. However we want the same enforcements over 
> > samba that a user would get on the local system, so the idea is to make 

> > [...]

> 1) doing user-space avc library calls is fine IF you can guarantee
> that the file system to which you are providing access is NOT
> accessible by any means other than through se-samba [or that
> any such access guarantees no race conditions].
> 
> i.e. you must, in effect, write your own userspace file system.

... just to be clear: isolating a filesystem from backdoor access
(i.e. the underlying filesystem, if it's a unix filesysyem, is NOT
accessible via any other means e.g. an NFS export) is not as bad
as it first seems.

you can always use the smbfs (or its newer more unix-centric
cifsfs cousins) linux kernel smb client filesystems to access
such an isolated userspace filesystem, and then re-export that
filesystem via other file servers (e.g. NFS).

i don't expect it to be very fast, it's not very friendly,
but it's minimal coding, minimal administrative setup and
it'll work.  fingers crossed.  :)

l.

p.s. as is done at the moment, you could always just keep on
giving samba unlimited policy access to the directories it
exports, but that's not the point, is it?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

On Tue, Jun 01, 2004 at 11:23:14AM +0200, Simo Sorce wrote:
> On Tue, 2004-06-01 at 01:29, Luke Kenneth Casson Leighton wrote:
> >  can i recommend - tridge, others - that you give serious
> >  consideration to writing an experimental samba 4 "NTVFS"
> >  SMB proxy client plugin?
> 
> That was the first VFS available for samba4, it has been used happily
> for many months now. And it's not that much experimental, it works
> really well and made a great job into finding out many errors in the
> core of samba4 and also samba3 handling of operations.
 
 brilliant!  excellent!

 that's actually _really_ good news.

 okay, so now it is possible to use that as the front-end for
 se-samba(4), and to run against a samba(3) server as the back-end!

 GREAT.

 okay, got a question for you.

 how does the samba4 smb client VFS proxy handle multiple
 TConX's over the same SMBsessionX?

 does it:

 a) try to multiplex them onto the same smb client connection?

 b) create a NEW smb client tcp connection over to the back-end
    smb server?

 if b) then the work needed to support se-samba is... like... done!

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

On Wed, Jun 02, 2004 at 08:33:06AM +1000, tridge@samba.org wrote:
> Volker,
> 
>  > It's a), everything is done via a single tcp connection. One reason is that we
>  > want to mirror the behaviour that the server we proxy towards gives us as
>  > closely as possible. Separate smb connections give a difference that might have
>  > influence on the server's behaviour.
> 
> Nope, the we open a new connection for each tree connect in that
> backend.
 
  BRILLIANT.  that's even better.

> It really doesn't matter though, as unless I have completely
> misunderstood se-linux, the TConX behaviour is completely irrelevant
> for the seteuid() problem that se-linux faces. All TConX does is
> establish a connection to a new directory (ignoring ancient share
> level security setups).

 the problem is that SE/Linux doesn't support seteuid.

> The relevant question is how SessionSetup is handled, because that is
> what determines the security context of requests. A client can combine
> SessionSetup with TConX in any way it wants to, with multiple TConX
> per SessionSetup or multiple SessionSetup per TConX. 
> 
> The CIFS proxy backend in Samba4 currently does a fixed SessionSetup
> using domain, username and password from parametric options in
> smb.conf. Andrew Bartlett has talked about adding authentication
> proxying as well, but it isn't done yet. When that is done the whole
> se-linux idea of using a CIFS proxy could be re-visited.
> 
> But really I think the whole idea of using a CIFS proxy for se-linux
> Samba is a non-starter. It would work, but it would be a "party
> trick", not a serious solution. Far better for the se-linux people to
> come up with a more general solution for handling servers that need to
> handle multiple security contexts on one network connection. In
> particular the solution should not be so intimately tied to CIFS.

 the solution is to have one process per security context.

 it is not possible to drop from the equivalent of root into
 the equivalent of a user-security-context (seteuid) and then
 back to the equivalent of root again.

 and SE/Linux is never going to have the equivalent of seteuid added.

 an SMB proxy which de-multiplexes all SMBsessionsetupXs and
 SMBtconXs is the "quickest" way to code up something that
 "works" that fits the requirements.

 it doesn't have to be fast.
 
 it doesn't have to be nice.
 
 it just has to work, and provide the required security semantics.

 "next" version can be an improvement on that.

 and, if i gather this correctly, the required semantics are already
 satisfied by using samba(4)'s SMB proxy and a samba(3) back-end.

 which is _great_.


 now, as i described a couple of times before, the alternatives
 are to write a special samba(4) NT-VFS plugin that communicates
 via a custom-written Inter-Process-Communication system to a
 de-multiplexing filesystem back-end.

 or, to design a back-end that forks() on SMBsessionsetupX
 and then forks() again on SMBtconX, and has some internal logic
 that manages to deal with locking, consistency, and successfully
 manages to communicate SMB requests through the double-layer of
 forks()

 that's a _lot_ more complex a solution than using SMB proxying.


> I would suggest that the se-linux people think about a potential
> user-space NFSv4 server, which faces exactly the same problem. Do the
> constraints imposed by se-linux mean that we will forever have to run
> NFSv4 servers in the kernel? Is that a good idea, given the security
> isolation aims of the project?

 i believe you may be misunderstanding the issues, which are relatively
 straightforward.

 1) root has no special "automatic" privileges, or more specifically,
    the uid "0" has no special "automatic" privileges, in SE/Linux.

	all uids are treated the same, and they only have the privileges
	which they are given, by the sysadmin.
 
 2) processes, which run under user-contexts (uids) have to be given
    permissions to do certain operations, such as execv(), open(),
	read once opened, stat, in fact pretty much everything is
	controlled.

 3) processes can, on creation of a child process make that
    child process "transition" to what they refer to as a new
	"domain".  e.g. auto_trans(samba_parent_t, samba_backend_t)
	and the new domain will of course have its _own_ set of
	capabilities (permissions).

[this is where it gets relevant to se-samba:]

 4) IT IS NOT POSSIBLE FOR A CHILD PROCESS TO RETURN TO THE
    PARENT'S DOMAIN.


 therefore, with the present design of samba(3) which uses
 seteuid() to jump to pretending to be a user context,
 such that file writes are done as that user, and then back to
 root to deal with a different TconX context, that completely
 breaks down.


 
 and yes, famd uses seteuid as well, and needs a total redesign
 along the same lines (multiple forked processes).

 andrew, i'm not entirely sure where you got the impression
 that it is necessary to run a kernel-space service (e.g. a
 kernel-space NFS server) in an SE/Linux environment.

 a user-space file server is perfectly sufficient, and much more
 preferable.


 if it wasn't for the fact that multiple SMB sessions can be made
 over the same TCP connection...

 hey.

 *thinks*.

 could someone please remind me: a Citrix Server does multiple
 SMB sessions over the same TCP connection, doesn't it?

 if that's the case, then... could someone confirm this statement
 for me:
 
 	"the samba(4) NT-VFS SMB proxy will do multiple TCP client
	 connections per SMB session"
	 
	 
 is that statement correct?

 because if so, then if the NT-VFS SMB proxy does multiple TCP
 connections per TConX, then yes, that _is_ a little excessive, but
 it's possible to live with that excess, and it can be solved
 by the libsmbclient supporting multiple TconX connections over the
 same TCP connection.

 the _most_ important thing is to have separate TCP connections
 for every SMBsessionsetupX.


 in case anyone's interested, i believe i may have modified
 samba-tng's libsmbclient code (or maybe the cliffs libsmbclient
 code) to be able to do multiple TconX's per TCP connection.

 it's quite straightforward.
 
 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

just wanted to correct some things and also to apologise for having a
bad memory.

now that i recall that it is the SMBsessionandX that needs to be
de-multiplexed (not the SMBtconX unless, like as tridge says,
the SMBsesssetupX is skipped as with share-level security) i should
make this clear.

however, my faulty memory, has, i believe, no impact on the
solution: the solution remains the same (albeit slower than
it could be, and clumsy).


under which circumstances, yes, tridge is right: 1) the TconX
behaviour is irrelevant (for seteuid()) and 2) the present
samba(4) SMB client NT-VFS plugin's behaviour is less than ideal
(in that it creates new tcp connections for every single TconX
as _well_).

... but it will work, and provide the required security semantics.

in the back-end se-samba(3) all that should be required is to run
pam_selinux.so.  and the front-end se-samba(4) just use the new
proxy plugin.


at a later date, improvements in the SMB NT-VFS proxy plugin can
be made (see cliffs or samba tng libsmb code for example, somewhere,
i promise!, of modified libsmb which can do multiple tconXes over
a single TCP connection).

l.

On Wed, Jun 02, 2004 at 08:33:06AM +1000, tridge@samba.org wrote:
> Volker,
> 
>  > It's a), everything is done via a single tcp connection. One reason is that we
>  > want to mirror the behaviour that the server we proxy towards gives us as
>  > closely as possible. Separate smb connections give a difference that might have
>  > influence on the server's behaviour.
> 
> Nope, the we open a new connection for each tree connect in that
> backend.
> 
> It really doesn't matter though, as unless I have completely
> misunderstood se-linux, the TConX behaviour is completely irrelevant
> for the seteuid() problem that se-linux faces. All TConX does is
> establish a connection to a new directory (ignoring ancient share
> level security setups).



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

btw if anyone is concerned about the speed of a multi-processed
arrangement (one daemon per service, where services equals
double-digits as in samba-tng) then of course all you need
to do to fix the fork() issue is to use the same approach as
apache(1&2): have a pool of pre-forked processes on tap.

in fact i am surprised that 1) smbd has not had such code added
to it already 2) that serious consideration has not been given
to using the new apache2 framework: careful analysis of libapr
shows significant code duplication and similarity in key areas.

l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Matthew Keller]

I started to write an SMB protocol plugin for Apache2. Then I got
distracted by a paying project and haven't been back at it. I spent many
hours planning out the requirements and it all looked very very doable.
My design had a separate "nmbd"-esque daemon just to deal with the
persistent LAN netbios-naming crap, but the "smbd"-esque part appeared
to be 100-160 manhours based on my Gantt. Of course, I could've grossly
underestimated it, but I don't think so. I'll probably hack back at it
sometime this summer. I really like the Apache2 infrastructure, and
after doing a couple toy protocols, wanted to jump in over my head. :) 

My $0.02.

On Thu, 2004-06-03 at 17:12, Luke Kenneth Casson Leighton wrote:
> btw if anyone is concerned about the speed of a multi-processed
> arrangement (one daemon per service, where services equals
> double-digits as in samba-tng) then of course all you need
> to do to fix the fork() issue is to use the same approach as
> apache(1&2): have a pool of pre-forked processes on tap.
> 
> in fact i am surprised that 1) smbd has not had such code added
> to it already 2) that serious consideration has not been given
> to using the new apache2 framework: careful analysis of libapr
> shows significant code duplication and similarity in key areas.
> 
> l.
> 
> _______________________________________________
> tng-technical at samba-tng dot org
> http://lists.samba-tng.org/mailman/listinfo.cgi/tng-technical
-- 
Matthew Keller
signat-url: http://mattwork.potsdam.edu/signat-url/
"No one ever says, 'I can't read that ASCII E-mail you sent me.'"

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: se-samba

[Luke Kenneth Casson Leighton]

hiya,

if you want to drastically cut down the amount of time you take,
look at the cliffs project.

you will find that there is a very simple IDL generator (written
in awk by andrew) which was used to auto-generated _stacks_ of code
which you would be completely mad to recreate manually.

the IDL file itself is taken DIRECTLY from the cifs specification
(text version) and i MEAN directly: i massaged it a bit and
added some grungy bits and ran the compiler.

if you need a change of / alternative / dual license on any
of the bits that i am responsible for, let me know.

l.


On Mon, Jun 14, 2004 at 04:00:48PM -0400, Matthew Keller wrote:
> I started to write an SMB protocol plugin for Apache2. Then I got
> distracted by a paying project and haven't been back at it. I spent many
> hours planning out the requirements and it all looked very very doable.
> My design had a separate "nmbd"-esque daemon just to deal with the
> persistent LAN netbios-naming crap, but the "smbd"-esque part appeared
> to be 100-160 manhours based on my Gantt. Of course, I could've grossly
> underestimated it, but I don't think so. I'll probably hack back at it
> sometime this summer. I really like the Apache2 infrastructure, and
> after doing a couple toy protocols, wanted to jump in over my head. :) 
> 
> My $0.02.
> 
> On Thu, 2004-06-03 at 17:12, Luke Kenneth Casson Leighton wrote:
> > btw if anyone is concerned about the speed of a multi-processed
> > arrangement (one daemon per service, where services equals
> > double-digits as in samba-tng) then of course all you need
> > to do to fix the fork() issue is to use the same approach as
> > apache(1&2): have a pool of pre-forked processes on tap.
> > 
> > in fact i am surprised that 1) smbd has not had such code added
> > to it already 2) that serious consideration has not been given
> > to using the new apache2 framework: careful analysis of libapr
> > shows significant code duplication and similarity in key areas.
> > 
> > l.
> > 
> > _______________________________________________
> > tng-technical at samba-tng dot org
> > http://lists.samba-tng.org/mailman/listinfo.cgi/tng-technical
> -- 
> Matthew Keller
> signat-url: http://mattwork.potsdam.edu/signat-url/
> "No one ever says, 'I can't read that ASCII E-mail you sent me.'"
> 

-- 
-- 
Information I post is with honesty, integrity, and the expectation that
you will take full responsibility if acting on the information contained,
and that, should you find it to be flawed or even mildly useful, you
will act with both honesty and integrity in return - and tell me.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.