New ideas on implementation on libsetrans.

New ideas on implementation on libsetrans.

[Daniel J Walsh]

After some discussion, we want to change the translation library into a 
long running daemon with a unix domain socket that libselinux can talk 
to for translation.  This eliminates the need to use dlopen, and link 
with -dl. 

Dan

-- 



--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Tue, 2005-09-13 at 14:35 -0400, Daniel J Walsh wrote:
> After some discussion, we want to change the translation library into a 
> long running daemon with a unix domain socket that libselinux can talk 
> to for translation.  This eliminates the need to use dlopen, and link 
> with -dl. 

I'm not sure that the dlopen is a real issue.  You could implement the
client-side communication with the daemon within libsetrans, i.e.
libsetrans becomes a generic library that connects to the daemon and
caches the mappings to reduce performance overhead on context
translation.  libselinux could still dlopen libsetrans and fall back to
no translation in the absence of it.  Then you don't need per-policy
versions of libsetrans, just of the daemon (or its configuration at
least).  Isn't that what TCS was doing anyway?

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Luke Kenneth Casson Leighton]

*grin* - is that the "are you completely mad??" daemon?  the one based
on the principles, considered insane, akin to winbindd?

:)

l.

p.s. need help doing the marshalling / unmarshalling, or
recommendation of techniques or tools to use (dceidl can
generate code to do pickling / unpickling of highly complex
data structures it takes _seconds_ to do - not hours of
hand-marshalling) let me know.

p.p.s. for god's sake don't go anywhere near dbus.  or xmlrpc
for that matter.

On Tue, Sep 13, 2005 at 02:35:06PM -0400, Daniel J Walsh wrote:
> After some discussion, we want to change the translation library into a 
> long running daemon with a unix domain socket that libselinux can talk 
> to for translation.  This eliminates the need to use dlopen, and link 
> with -dl. 
> 
> Dan
> 
> -- 
> 
> 
> 
> --
> 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.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
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: New ideas on implementation on libsetrans.

[Darrel Goeddel]

Daniel J Walsh wrote:
> After some discussion, we want to change the translation library into a 
> long running daemon with a unix domain socket that libselinux can talk 
> to for translation.  This eliminates the need to use dlopen, and link 
> with -dl.
> Dan
> 

I mentioned the idea of socket communications when I initially presented
the translation framework patch.  My comment was that imposing a mechanism
like that that on all translators may be a little much.  The use of the
dlopen'd library make it easy for someone to use flat files, UDS, TCP...
Our current translation library is actually just a "communication manager"
that talks via UDS to a daemon process which manages the labels.

There is an upshot to using UDS in libselinux - it makes the policy for all
users of libselinux generic.  The callers of libselinux functions only need
to be able to use the socket.  Currently, differing translators could require
different access rights for libselinux users.  In the socket scheme, only the
daemon needs the "specific" access rights to do the translations - that is
much easier to manage.

I like the earlier idea on libsetrans about choosing a library based off
of the policy type.  Would something similar be considered here (like
/var/setrans/mls, /var/setrans/targeted, etc., where all of the sockets
share the same type)?

Have you put any thought into the language that libselinux and the daemons
would speak over the socket?

-- 

Darrel

--
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: New ideas on implementation on libsetrans.

[Daniel J Walsh]

Darrel Goeddel wrote:

> Daniel J Walsh wrote:
>
>> After some discussion, we want to change the translation library into 
>> a long running daemon with a unix domain socket that libselinux can 
>> talk to for translation.  This eliminates the need to use dlopen, and 
>> link with -dl.
>> Dan
>>
>
> I mentioned the idea of socket communications when I initially presented
> the translation framework patch.  My comment was that imposing a 
> mechanism
> like that that on all translators may be a little much.  The use of the
> dlopen'd library make it easy for someone to use flat files, UDS, TCP...
> Our current translation library is actually just a "communication 
> manager"
> that talks via UDS to a daemon process which manages the labels.

Our idea is to put this all in the backend (Yes Luke like winbind :^))
So the backend SELINUX Daemon would have a plugin interface to allow 
translation via
local file. ldap, MITRE Library ...

>
> There is an upshot to using UDS in libselinux - it makes the policy 
> for all
> users of libselinux generic.  The callers of libselinux functions only 
> need
> to be able to use the socket.  Currently, differing translators could 
> require
> different access rights for libselinux users.  In the socket scheme, 
> only the
> daemon needs the "specific" access rights to do the translations - 
> that is
> much easier to manage.

Yes we are having problems with linking against the library and having 
different plugins to the library just doesnot feel right.

>
> I like the earlier idea on libsetrans about choosing a library based off
> of the policy type.  Would something similar be considered here (like
> /var/setrans/mls, /var/setrans/targeted, etc., where all of the sockets
> share the same type)?
>
Yes except there would only be a single UDS say 
/var/run/selinux/seinux_domain.

Then the daemon would choose the appropriate library to use, either via 
the policy that is installed or via a config file.

> Have you put any thought into the language that libselinux and the 
> daemons
> would speak over the socket?
>
I like ASCII... Of course if someone wants to take the ball and run with 
it, it would be great.



-- 



--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Tue, 2005-09-13 at 15:54 -0400, Daniel J Walsh wrote:
> Yes we are having problems with linking against the library and having 
> different plugins to the library just doesnot feel right.

I'm still not sure what the problem is with dlopen'ing libsetrans, and
letting it take care of the communication (and caching) _if_ any
translation is desired at all.  Why bloat libselinux with that
infrastructure for people who don't want any label translation?

I understand that the attempt to dlopen a per-policytype libsetrans was
getting complicated, although I'm not sure why you couldn't just
dlopen /usr/lib/libsetrans.so symlink and use alternatives to manage
what that references outside of libselinux.

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2005-09-13 at 15:54 -0400, Daniel J Walsh wrote:
>  
>
>>Yes we are having problems with linking against the library and having 
>>different plugins to the library just doesnot feel right.
>>    
>>
>
>I'm still not sure what the problem is with dlopen'ing libsetrans, and
>letting it take care of the communication (and caching) _if_ any
>translation is desired at all.  Why bloat libselinux with that
>infrastructure for people who don't want any label translation?
>
>I understand that the attempt to dlopen a per-policytype libsetrans was
>getting complicated, although I'm not sure why you couldn't just
>dlopen /usr/lib/libsetrans.so symlink and use alternatives to manage
>what that references outside of libselinux.
>
>  
>
Most of the people I talk to in Red Hat don't like alternatives.    We 
can change to just use libsetrans and implement to communication in this 
library, but I don't see that as adding much value.

-- 



--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Tue, 2005-09-13 at 16:04 -0400, Daniel J Walsh wrote:
> Most of the people I talk to in Red Hat don't like alternatives.    We 
> can change to just use libsetrans and implement to communication in this 
> library, but I don't see that as adding much value.

The advantage of putting the communication/caching code into a separate
library (libsetrans) rather than into libselinux directly are:
- it leaves open the option of omitting the code for the communications
and caching altogether for systems that have no need for label
translation,
- it leaves open the option of providing a libsetrans implementation
that deals with flat files directly rather than communicating over a
socket.

The only disadvantage that I see is that users of the static libselinux
don't get the translation by default; they have to explicitly link with
libsetrans themselves and invoke the translation interfaces if they want
translation.  But such users should be very few and manageable.  prelink
doesn't truly need translation; it just needs getfilecon to always
return a context that can be used in a subsequent setfilecon call, and
James' kernel patch addresses that concern.

Am I missing other disadvantages?
 
-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2005-09-13 at 16:04 -0400, Daniel J Walsh wrote:
>  
>
>>Most of the people I talk to in Red Hat don't like alternatives.    We 
>>can change to just use libsetrans and implement to communication in this 
>>library, but I don't see that as adding much value.
>>    
>>
>
>The advantage of putting the communication/caching code into a separate
>library (libsetrans) rather than into libselinux directly are:
>- it leaves open the option of omitting the code for the communications
>and caching altogether for systems that have no need for label
>translation,
>  
>
If no one is listening on  the socket or the socket does not exist you 
get the same behavior.

>- it leaves open the option of providing a libsetrans implementation
>that deals with flat files directly rather than communicating over a
>socket.
>
>The only disadvantage that I see is that users of the static libselinux
>don't get the translation by default; they have to explicitly link with
>libsetrans themselves and invoke the translation interfaces if they want
>translation.  But such users should be very few and manageable.  prelink
>doesn't truly need translation; it just needs getfilecon to always
>return a context that can be used in a subsequent setfilecon call, and
>James' kernel patch addresses that concern.
>
>  
>
I see packaging problems and requiring objects to link with -dl.  We are 
basically looking at a packaging problem
now, which is why we are bringing this up. 

I have added Nalin to the message to get his comments.

>Am I missing other disadvantages?
> 
>  
>


-- 



--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Tue, 2005-09-13 at 16:33 -0400, Daniel J Walsh wrote:
> If no one is listening on  the socket or the socket does not exist you 
> get the same behavior.

You get the same behavior (i.e. no translation), but the client-side
code for the communication and caching is still in libselinux.  Whereas
with it in libsetrans, you don't have that problem.  You just don't ship
a libsetrans, and libselinux gracefully proceeds when the dlopen fails.

Further, in the case where you do have translation, when you want to
modify that translation protocol, you don't have to touch libselinux at
all.

> I see packaging problems and requiring objects to link with -dl.  We are 
> basically looking at a packaging problem
> now, which is why we are bringing this up. 

I understand the issue with prelink due to being statically linked, but
how many programs that link with libselinux are statically linked?
Even /sbin/init is dynamically linked (surprisingly to me when I first
noticed it long ago in Red Hat Linux).

> I have added Nalin to the message to get his comments.

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2005-09-13 at 16:33 -0400, Daniel J Walsh wrote:
>  
>
>>If no one is listening on  the socket or the socket does not exist you 
>>get the same behavior.
>>    
>>
>
>You get the same behavior (i.e. no translation), but the client-side
>code for the communication and caching is still in libselinux.  Whereas
>with it in libsetrans, you don't have that problem.  You just don't ship
>a libsetrans, and libselinux gracefully proceeds when the dlopen fails.
>
>Further, in the case where you do have translation, when you want to
>modify that translation protocol, you don't have to touch libselinux at
>all.
>
>  
>
>>I see packaging problems and requiring objects to link with -dl.  We are 
>>basically looking at a packaging problem
>>now, which is why we are bringing this up. 
>>    
>>
>
>I understand the issue with prelink due to being statically linked, but
>how many programs that link with libselinux are statically linked?
>Even /sbin/init is dynamically linked (surprisingly to me when I first
>noticed it long ago in Red Hat Linux).
>
>  
>
>>I have added Nalin to the message to get his comments.
>>    
>>
>
>  
>
Ok I succumb, but we will go back to original implementation of 
libsetrans for now, and require anyone wishing to change the behaviour 
to replace our version with their own.  so dlopen(libsetrans.so.1) will 
work.

Eventually our version of libsetrans will use a UDS interface to talk to 
a long running daemon.

Dan


-- 



--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Tue, 2005-09-13 at 17:19 -0400, Daniel J Walsh wrote:
> Ok I succumb, but we will go back to original implementation of 
> libsetrans for now, and require anyone wishing to change the behaviour 
> to replace our version with their own.  so dlopen(libsetrans.so.1) will 
> work.
> 
> Eventually our version of libsetrans will use a UDS interface to talk to 
> a long running daemon.

Ok.  Do you agree that libselinux should be dlopen'ing libsetrans.so
(and thus using the symlink that already exists under /usr/lib to
whatever the latest version is under /lib) rather than specifically
dlopen'ing libsetrans.so.0 as it does now?  Of course, it may not matter
in practice as I can't see the interface ever changing (at least in a
way that requires bumping the .so version), but it seems cleaner.  

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2005-09-13 at 17:19 -0400, Daniel J Walsh wrote:
>  
>
>>Ok I succumb, but we will go back to original implementation of 
>>libsetrans for now, and require anyone wishing to change the behaviour 
>>to replace our version with their own.  so dlopen(libsetrans.so.1) will 
>>work.
>>
>>Eventually our version of libsetrans will use a UDS interface to talk to 
>>a long running daemon.
>>    
>>
>
>Ok.  Do you agree that libselinux should be dlopen'ing libsetrans.so
>(and thus using the symlink that already exists under /usr/lib to
>whatever the latest version is under /lib) rather than specifically
>dlopen'ing libsetrans.so.0 as it does now?  Of course, it may not matter
>in practice as I can't see the interface ever changing (at least in a
>way that requires bumping the .so version), but it seems cleaner.  
>
>  
>
I agree.  Open /usr/lib/libsetrans.so

-- 



--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Wed, 2005-09-14 at 15:23 -0400, Nalin Dahyabhai wrote:
> I would disagree with that.  In giving the setrans library a soname,
> you've provided some means of making sure that you don't load an
> incompatible version of the library if the interface which that library
> provides ever differs from what libselinux expects.
> 
> If libselinux is changed to dlopen() it using a symlink which points to
> whichever version is current, then that benefit is gone.

Ok, fair point.  We'll leave it alone then (have to go and revert that
patch now...).

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Steve G]

>Am I missing other disadvantages?

How often would this library be called? Is it a performance hit for programs to
parse the flat file everytime they run? I'm thinking mostly of coreutils style
programs that would be in shell scripts. What program would be the heaviest user
of the translation library? Is anything other than translation being considered? 

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Wed, 2005-09-14 at 06:03 -0700, Steve G wrote:
> >Am I missing other disadvantages?
> 
> How often would this library be called? Is it a performance hit for programs to
> parse the flat file everytime they run? I'm thinking mostly of coreutils style
> programs that would be in shell scripts. What program would be the heaviest user
> of the translation library? Is anything other than translation being considered? 

The issue being discussed was if we changed the existing libsetrans in
Fedora to obtain context translations from a separate daemon (as
proposed by Dan, and also the way in which TCS handles it) rather than
directly performing translation itself, should we fold the libsetrans
code (which would then consist of just the client-side communication and
caching code) into libselinux or keep it as a separate optional library
that is dlopen'd by libselinux during library initialization.  I favored
keeping it separate so that one still has the options of no libsetrans
at all or a libsetrans that performs direct translation as alternatives.

The context translation functions are called all the time by libselinux
functions if context translation is enabled (which is determined by
libselinux during initialization based on whether the dlopen and dlsym
lookups succeed), so any program that gets or sets a context would
exercise them.  A simple ls -Z would exercise them.  But the mapping
file itself is typically only loaded once, during library initialization
for the direct libsetrans or upon daemon start or SIGHUP for the
daemon-based one, and the actual context translation functions are just
performing lookups on in-memory data structures.  When using the daemon,
you have the overhead of the communication with the daemon, so you would
likely want libsetrans to cache the results in memory (but you then have
the issue of flushing the cache on the client side when there is a
change on the server side).

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Steve G]

>> >Am I missing other disadvantages?
>> 
>> How often would this library be called? Is it a performance hit for programs
to
>> parse the flat file everytime they run? I'm thinking mostly of coreutils style
>> programs that would be in shell scripts. What program would be the heaviest
>> user of the translation library? Is anything other than translation being 
>> considered? 
>
>so any program that gets or sets a context would exercise them.

My concern which lead to consideration of the daemon approach is the performance
penalty imposed by dlopen & dlsym as well as parsing the configuration each time
a program starts up. dlopen is a heavy function call. Communication across a
af_unix socket is likely to be faster since there are fewer syscalls. The
question is are there enough programs that would suffer a performance hit that we
should look at making a daemon. Admittedly the daemon would be simple and it
would load the plugin. I also was thinking about doing the config from shared
memory to avoid all the parsing on startup. Yes, there would need to be a cache
scrubber that times out the cache entries - which could be coordinated with
inotify. (If inotify never says the config changed, no need to timeout the
cache.)

> A simple ls -Z would exercise them. But the mapping file itself is typically
> only loaded once

Are there any other common utilities that would cause a performance hit? pam
modules for example. If its just ls -Z, I'm not too worried. I do worry if it
gets into something that is performance sensitive like dbus, nscd, etc.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Wed, 2005-09-14 at 10:25 -0700, Steve G wrote:
> Are there any other common utilities that would cause a performance hit? pam
> modules for example. If its just ls -Z, I'm not too worried. I do worry if it
> gets into something that is performance sensitive like dbus, nscd, etc.

Anything that gets a context from libselinux or passes a context to it.
That would include pam_selinux, dbusd, nscd, ...

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Wed, 2005-09-14 at 10:25 -0700, Steve G wrote:
> My concern which lead to consideration of the daemon approach is the performance
> penalty imposed by dlopen & dlsym as well as parsing the configuration each time
> a program starts up. dlopen is a heavy function call. Communication across a
> af_unix socket is likely to be faster since there are fewer syscalls.

BTW, I'd want to see measurements there before jumping to that
assumption.  Don't forget the socket setup and context switch overhead.

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Luke Kenneth Casson Leighton]

On Wed, Sep 14, 2005 at 02:01:51PM -0400, Stephen Smalley wrote:
> On Wed, 2005-09-14 at 10:25 -0700, Steve G wrote:
> > My concern which lead to consideration of the daemon approach is the performance
> > penalty imposed by dlopen & dlsym as well as parsing the configuration each time
> > a program starts up. dlopen is a heavy function call. Communication across a
> > af_unix socket is likely to be faster since there are fewer syscalls.
> 
> BTW, I'd want to see measurements there before jumping to that
> assumption.  Don't forget the socket setup 

 there are other ways: shared memory.

 samba contains _stacks_ of uses of shared memory, plus if you use the
 right google search keywords it's possible to find a library with a
 unix-domain-socket-like-looking-interface that actually uses shared
 memory behind it.

 it's a library written by sun, iirc.

> and context switch overhead.
 
 oops :)


--
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: New ideas on implementation on libsetrans.

[Luke Kenneth Casson Leighton]

On Tue, Sep 13, 2005 at 03:54:58PM -0400, Daniel J Walsh wrote:
> >Have you put any thought into the language that libselinux and the 
> >daemons
> >would speak over the socket?
> >
> I like ASCII... Of course if someone wants to take the ball and run with 
> it, it would be great.
 
 before making a decision: what level of complexity are we looking at?

 if you're looking at a horrendous set of interlinked structs, combining
 variable-length arrays of unions containing further variable-length
 arrays of structs, such as this:

 http://cvs.sourceforge.net/viewcvs.py/oser/exchange5.5/exploration/test/emsabp/emsabp.idl?rev=1.1&view=markup

 then you would be completely and utterly insane to do this by hand.

 if, however, on the other hand, you are looking at a simple "gimme one
 bit of data" "here you go" then yeh, ascii would be fine (and, to be
 honest, infinitely preferable).


 winbindd needs to handle binary data structures, and _fortunately_ it
 has access to a whole boat-load of MSRPC infrastructure / pickling
 code.

 so even though it's handling data structures such as NET_USER_INFO_3
 variable-length optional-extras nightmares, the code already exists
 (which was created by hand, and NET_USER_INFO_3 on its own took several
 hours to do) so we use it.

 
 one technique deployed by winbindd is to have a "fixed size" data blob
 and an optional "variable length" data blob.

 the "fixed size" one is the union of a whole stack of structs,
 with an integer "info level" which is the "command", and that
 info level specifies which of the structs in the union is actually
 contained in the fixed-size data blob.

 it's a technique known as "encapsulated unions".


 so.

 what do the data structures look like?

 tell me they're nice and simple...


--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Tue, 2005-09-13 at 22:22 +0100, Luke Kenneth Casson Leighton wrote:
>  what do the data structures look like?
> 
>  tell me they're nice and simple...

All we are talking about is "here is a raw context string, please give
me a human-readable one" and vice versa.

-- 
Stephen Smalley
National Security Agency


--
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: New ideas on implementation on libsetrans.

[Luke Kenneth Casson Leighton]

On Wed, Sep 14, 2005 at 07:58:57AM -0400, Stephen Smalley wrote:
> On Tue, 2005-09-13 at 22:22 +0100, Luke Kenneth Casson Leighton wrote:
> >  what do the data structures look like?
> > 
> >  tell me they're nice and simple...
> 
> All we are talking about is "here is a raw context string, please give
> me a human-readable one" and vice versa.

 pffh, lots of fuss then :)  ascii it is!


--
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: New ideas on implementation on libsetrans.

[Steve G]

> pffh, lots of fuss then :)  ascii it is!

I think people that speak different languages than english may want to use their
word for "confidential" to be more meaningful to the users. I hope we are taking
utf8 into account.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: New ideas on implementation on libsetrans.

[Stephen Smalley]

On Fri, 2005-09-16 at 10:18 -0700, Steve G wrote:
> > pffh, lots of fuss then :)  ascii it is!
> 
> I think people that speak different languages than english may want to use their
> word for "confidential" to be more meaningful to the users. I hope we are taking
> utf8 into account.

Not presently.  Patches welcome ;)

-- 
Stephen Smalley
National Security Agency


--
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.