Hello,
I restart learning Lisp, so maybe this is FAQ, but I did not find any
apropriate information. If there is one, please give me a hint where/how
to find informations like this.
AFAIK I believe that some data has to be hidden for security reasons
(passwords, private keys ...).
Using libraries from others, I think that one should be able to restrict
read/write access to some data.
I wonder if data-hiding can be done with closures.
How can one access data inside a closure from outside?
? (let ((e 1))
(defun closure-1 () e))
CLOSURE-1
? (closure-1)
1
? e
Error: unbound variable
I mean, is it possible to change the value of the e in closure-1 from
outside?
Thanks for infos,
Bernd
--
T_a_k_e__c_a_r_e__o_f__y_o_u_r__R_I_G_H_T_S.
P_r_e_v_e_n_t__L_O_G_I_C--P_A_T_E_N_T_S
http://www.ffii.org, http://www.nosoftwarepatents.org
Bernd Schmitt wrote:
> Hello,
> I restart learning Lisp, so maybe this is FAQ, but I did not find any
> apropriate information. If there is one, please give me a hint where/how
> to find informations like this.
> AFAIK I believe that some data has to be hidden for security reasons
> (passwords, private keys ...).
> Using libraries from others, I think that one should be able to restrict
> read/write access to some data.
> I wonder if data-hiding can be done with closures.
> How can one access data inside a closure from outside?
>
> ? (let ((e 1))
> (defun closure-1 () e))
> CLOSURE-1
> ? (closure-1)
> 1
> ? e
> Error: unbound variable
>
> I mean, is it possible to change the value of the e in closure-1 from
> outside?
>
>
> Thanks for infos,
> Bernd
>
>
>
What you have done here with LET is create a lexically scoped variable
named E. Once the LET form is done the binding which it established for
E no longer exists--except for the little detail that your function
CLOSURE-1 keeps that binding alive internally. But outside of the LET
form that binding is otherwise inaccessible.
Lexical variables in Lisp naturally have lexical scope, but they also
exhibit what is known as indefinite extent. This means that as long as a
variable can be referenced it will continue to exist. Your closure
causes that binding of E to persist as long as the function exists.
The only way to modify E is to define another closure within the same
LET form:
(let ((e 1))
(defun get-e () e)
(defun set-e (x) (setf e x)))
Now SET-E shares the same binding of E as GET-E does and can therefore
modify it.
Aloha,
David Sletten
On 17.04.2006 00:16, David Sletten wrote:
> Bernd Schmitt wrote:
Thanks for your answer. Do I understand you right, if I say, there is no
way in CL to change symbols which only live in a closure?
I am currently reading "Successful Lisp". This code is from the book:
(defun make-secret-keeper ()
(let ((password nil)
(secret nil))
#'(lambda (operation &rest arguments)
(ecase operation
(set-password
(let ((new-passwd (first arguments)))
(if password
'|Can't - already set|
(setq password new-passwd))))
(change-password
(let ((old-passwd (first arguments))
(new-passwd (second arguments)))
(if (eq old-passwd password)
(setq password new-passwd)
'|Not changed|)))
(set-secret
(let ((passwd (first arguments))
(new-secret (second arguments)))
(if (eq passwd password)
(setq secret new-secret)
'|Wrong password|)))
(get-secret
(let ((passwd (first arguments)))
(if (eq passwd password)
secret
'|Sorry|)))))))
MAKE-SECRET-KEEPER
So I /was/ wondering, if there is really no way to access/change symbols
which live only inside a closure and if there are other ways to do this
for CLOS.
I think the answer Rainer gave me, helps here ( to be honest, I did not
understand Pascal's answer fully).
Thanks for your answer,
Bernd
--
https://gna.org/projects/mipisti - (microscope) picture stitching
T_a_k_e__c_a_r_e__o_f__y_o_u_r__R_I_G_H_T_S.
P_r_e_v_e_n_t__L_O_G_I_C--P_A_T_E_N_T_S
http://www.ffii.org, http://www.nosoftwarepatents.org
Bernd Schmitt <··················@gmx.net> writes:
> On 17.04.2006 00:16, David Sletten wrote:
>> Bernd Schmitt wrote:
>
> Thanks for your answer. Do I understand you right, if I say, there is no
> way in CL to change symbols which only live in a closure?
Not really. The debugger, DISASSEMBLE, and other functions may give
access. Since you've used ECASE, it would be trivial to drop into the
debugger inside your closure. The debugger may give access to the
closure variables:
[98]> (defvar *closure*
(let ((secret "The Emperor is naked."))
(lambda (password)
(if (= password 42) secret (error "Bad password")))))
*CLOSURE*
[99]> (funcall *closure* 2)
*** - Bad password
The following restarts are available:
ABORT :R1 ABORT
Break 1 [100]> :bt
<1> #<SYSTEM-FUNCTION EXT:SHOW-STACK> 3
<2> #<COMPILED-FUNCTION SYSTEM::PRINT-BACKTRACE>
<3> #<COMPILED-FUNCTION SYSTEM::DEBUG-BACKTRACE>
<4> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> 2
<5> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2-2>
<6> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS> 2
<7> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2>
<8> #<SYSTEM-FUNCTION SYSTEM::DRIVER>
<9> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP>
<10> #<SYSTEM-FUNCTION INVOKE-DEBUGGER> 1
<11> #<SYSTEM-FUNCTION ERROR> 1
<12> #<SPECIAL-OPERATOR IF>
EVAL frame for form (IF (= PASSWORD 42) SECRET (ERROR "Bad password"))
APPLY frame for call (:LAMBDA '2)
<13>
#<FUNCTION :LAMBDA (PASSWORD)
(IF (= PASSWORD 42) SECRET (ERROR "Bad password"))> 1
<14> #<SYSTEM-FUNCTION FUNCALL> 2
EVAL frame for form (FUNCALL *CLOSURE* 2)
Printed 14 frames
Break 1 [100]> secret
"The Emperor is naked."
Break 1 [100]>
or the disassembler:
[111]> (disassemble *closure*)
Disassembly of function :LAMBDA
(CONST 0) = 42
(CONST 1) = #(SECRET "The Emperor is naked." NIL)
(CONST 2) = 1
(CONST 3) = "Bad password"
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
10 byte-code instructions:
0 (LOAD&PUSH 1)
1 (CONST&PUSH 0) ; 42
2 (CALLSR&JMPIFNOT 1 45 L11) ; =
6 (CONST&PUSH 1) ; #(SECRET ...)
7 (CONST 2) ; 1
8 (SVREF)
9 (SKIP&RET 2)
11 L11
11 (CONST&PUSH 3) ; "Bad password"
12 (CALLSR 0 29) ; ERROR
NIL
[112]>
Moreover, there may be a way in the implementation dependent packages,
such as "EXT", "INTERNAL", "SYS", or "SYSTEM", etc.:
[119]> (setf *closure* (compile nil *closure*))
#<COMPILED-FUNCTION NIL>
[120]> (SYSTEM::CLOSURE-CONSTS *closure*)
(42 #(SECRET "The Emperor is naked." NIL) 1 "Bad password")
[121]>
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
In article <·························@news.freenet.de>,
Bernd Schmitt <··················@gmx.net> wrote:
> Hello,
> I restart learning Lisp, so maybe this is FAQ, but I did not find any
> apropriate information. If there is one, please give me a hint where/how
> to find informations like this.
> AFAIK I believe that some data has to be hidden for security reasons
> (passwords, private keys ...).
> Using libraries from others, I think that one should be able to restrict
> read/write access to some data.
> I wonder if data-hiding can be done with closures.
> How can one access data inside a closure from outside?
>
> ? (let ((e 1))
> (defun closure-1 () e))
> CLOSURE-1
> ? (closure-1)
> 1
> ? e
> Error: unbound variable
>
> I mean, is it possible to change the value of the e in closure-1 from
> outside?
Not without platform specific tools (like a debugger).
Another way to hide data is to use uninterned symbols and CLOS.
For example:
(defclass baz ()
((#:foo :reader baz-foo :initform 1)))
CL-USER 31 > (let ((i1 (make-instance 'baz)))
(print (baz-foo i1))
(print (slot-value i1 '#:foo)))
1
Error: The slot #:FOO is missing from #<BAZ 100CD287> (of class #<STANDARD-CLASS BAZ 10BE7863>), when reading the value.
1 (abort) Return to level 0.
2 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other options
Here we can restrict slot-access to a predefined reader function.
The reader function can access the slot. Using SLOT-VALUE and
(SETF SLOT-VALUE) is no longer possible (unless somebody can
provide the uninterned symbol to these functions, which usually
is unlikely).
--
http://lispm.dyndns.org/
Rainer Joswig wrote:
> In article <·························@news.freenet.de>,
> Bernd Schmitt <··················@gmx.net> wrote:
>
>> Hello,
>> I restart learning Lisp, so maybe this is FAQ, but I did not find any
>> apropriate information. If there is one, please give me a hint where/how
>> to find informations like this.
>> AFAIK I believe that some data has to be hidden for security reasons
>> (passwords, private keys ...).
>> Using libraries from others, I think that one should be able to restrict
>> read/write access to some data.
>> I wonder if data-hiding can be done with closures.
>> How can one access data inside a closure from outside?
>>
>> ? (let ((e 1))
>> (defun closure-1 () e))
>> CLOSURE-1
>> ? (closure-1)
>> 1
>> ? e
>> Error: unbound variable
>>
>> I mean, is it possible to change the value of the e in closure-1 from
>> outside?
>
> Not without platform specific tools (like a debugger).
>
>
>
> Another way to hide data is to use uninterned symbols and CLOS.
>
>
> For example:
>
>
> (defclass baz ()
> ((#:foo :reader baz-foo :initform 1)))
>
> CL-USER 31 > (let ((i1 (make-instance 'baz)))
> (print (baz-foo i1))
> (print (slot-value i1 '#:foo)))
>
> 1
> Error: The slot #:FOO is missing from #<BAZ 100CD287> (of class #<STANDARD-CLASS BAZ 10BE7863>), when reading the value.
> 1 (abort) Return to level 0.
> 2 Return to top loop level 0.
>
> Type :b for backtrace, :c <option number> to proceed, or :? for other options
>
>
>
> Here we can restrict slot-access to a predefined reader function.
> The reader function can access the slot. Using SLOT-VALUE and
> (SETF SLOT-VALUE) is no longer possible (unless somebody can
> provide the uninterned symbol to these functions, which usually
> is unlikely).
(mapcar #'slot-definition-name
(class-slots (class-of object)))
Therefore, I think that using an non-exported symbol as a slot name is
sufficient.
Encapsulation is overrated, except in rare cases. The level of
information hiding that helps programmers to avoid standing on each
other's feet is typically sufficient. If you are worried about security,
the level of encapsulation that programming language provides is
probably not the most important issue. (IMHO)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
On 16.04.2006 23:03, Pascal Costanza wrote:
> Rainer Joswig wrote:
>> In article <·························@news.freenet.de>,
>> Bernd Schmitt <··················@gmx.net> wrote:
>>> I mean, is it possible to change the value of the e in closure-1 from
>>> outside?
>> Not without platform specific tools (like a debugger).
>> Another way to hide data is to use uninterned symbols and CLOS.
> (mapcar #'slot-definition-name
> (class-slots (class-of object)))
Sorry this seems to be outside my knowledge of CLOS, I will have to read
further in my current lisp-book to understand this ("Successful Lisp"[1]).
> Therefore, I think that using an non-exported symbol as a slot name is
> sufficient.
> Encapsulation is overrated, except in rare cases. The level of
> information hiding that helps programmers to avoid standing on each
> other's feet is typically sufficient. If you are worried about security,
> the level of encapsulation that programming language provides is
> probably not the most important issue. (IMHO)
You maybe have more knowledge as I, so I will not start arguing on this.
Let's say, I am just curious about what is possible to make data private.
Thanks for your answer,
Bernd
[1] I switched temporarily from "Paradigms of Artificial Intelligence
Programming" to "Successful CL", because this is the nth time of trying
to learn lisp while having a real life (family, totally non coding job)
and "Successful CL" is ~180 pages to read in order to get an overview.
On the other hand I have PAIP, "CL A Gentle Introduction to Symbolic
Computation" and "Practical CL" available, so if an explanation is
inside of one of them, please point me there.
--
https://gna.org/projects/mipisti - (microscope) picture stitching
T_a_k_e__c_a_r_e__o_f__y_o_u_r__R_I_G_H_T_S.
P_r_e_v_e_n_t__L_O_G_I_C--P_A_T_E_N_T_S
http://www.ffii.org, http://www.nosoftwarepatents.org
Bernd Schmitt wrote:
> On 16.04.2006 23:03, Pascal Costanza wrote:
>> Rainer Joswig wrote:
>>> In article <·························@news.freenet.de>,
>>> Bernd Schmitt <··················@gmx.net> wrote:
>
>>>> I mean, is it possible to change the value of the e in closure-1 from
>>>> outside?
>>> Not without platform specific tools (like a debugger).
>
>>> Another way to hide data is to use uninterned symbols and CLOS.
>
>> (mapcar #'slot-definition-name
>> (class-slots (class-of object)))
> Sorry this seems to be outside my knowledge of CLOS, I will have to read
> further in my current lisp-book to understand this ("Successful Lisp"[1]).
I don't think this is explained in any of the books you mentioned, since
this is part of the CLOS metaobject protocol. Don't worry, this part is
actually quite simple:
- (class-of object) returns the class the object is an instance of.
- (class-slots some-class) returns all the slots that are defined for a
class.
- (slot-definition-name some-slot) returns the name of a slot.
This means that even if you use an uninterned symbol as the name of a
slot, you can still determine that name by iterating through all slots
of a class and get their names via the code above.
I hope this helps.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
On 17.04.2006 16:47, Pascal Costanza wrote:
> Bernd Schmitt wrote:
>> On 16.04.2006 23:03, Pascal Costanza wrote:
>>> Rainer Joswig wrote:
>>>> In article <·························@news.freenet.de>,
>>>> Bernd Schmitt <··················@gmx.net> wrote:
>>>> Another way to hide data is to use uninterned symbols and CLOS.
>>
>>> (mapcar #'slot-definition-name
>>> (class-slots (class-of object)))
trying
(class-slots 'baz)
(with 'baz baz i1 'i1 (i have created i1 on toplevel)) I get an error:
"Error in KERNEL:%COERCE-TO-FUNCTION: the function CLASS-SLOTS is
undefined.
[Condition of type UNDEFINED-FUNCTION]"
> This means that even if you use an uninterned symbol as the name of a
> slot, you can still determine that name by iterating through all slots
> of a class and get their names via the code above.
Ok, I maybe used class-slots wrong, but even if i can figure out the
slots of a class/object - one can neither read nor change a slot from
outside its accessors if it is not interned, right (IIUC) or false?
Thanks anyway,
Bernd
--
https://gna.org/projects/mipisti - (microscope) picture stitching
T_a_k_e__c_a_r_e__o_f__y_o_u_r__R_I_G_H_T_S.
P_r_e_v_e_n_t__L_O_G_I_C--P_A_T_E_N_T_S
http://www.ffii.org, http://www.nosoftwarepatents.org
From: Bill Atkins
Subject: Re: private data hiding via closures?
Date:
Message-ID: <87zmik19ir.fsf@rpi.edu>
Bernd Schmitt <··················@gmx.net> writes:
> On 17.04.2006 16:47, Pascal Costanza wrote:
>> Bernd Schmitt wrote:
>>> On 16.04.2006 23:03, Pascal Costanza wrote:
>>>> Rainer Joswig wrote:
>>>>> In article <·························@news.freenet.de>,
>>>>> Bernd Schmitt <··················@gmx.net> wrote:
>
>>>>> Another way to hide data is to use uninterned symbols and CLOS.
>>>
>>>> (mapcar #'slot-definition-name
>>>> (class-slots (class-of object)))
> trying
>
> (class-slots 'baz)
>
> (with 'baz baz i1 'i1 (i have created i1 on toplevel)) I get an error:
>
> "Error in KERNEL:%COERCE-TO-FUNCTION: the function CLASS-SLOTS is
> undefined.
> [Condition of type UNDEFINED-FUNCTION]"
>
>
>
>> This means that even if you use an uninterned symbol as the name of a
>> slot, you can still determine that name by iterating through all slots
>> of a class and get their names via the code above.
> Ok, I maybe used class-slots wrong, but even if i can figure out the
> slots of a class/object - one can neither read nor change a slot from
> outside its accessors if it is not interned, right (IIUC) or false?
>
>
>
> Thanks anyway,
> Bernd
>
>
>
> --
> https://gna.org/projects/mipisti - (microscope) picture stitching
> T_a_k_e__c_a_r_e__o_f__y_o_u_r__R_I_G_H_T_S.
> P_r_e_v_e_n_t__L_O_G_I_C--P_A_T_E_N_T_S
> http://www.ffii.org, http://www.nosoftwarepatents.org
Since CLASS-SLOTS is part of the metaobject protocol and the
metaobject protocol never made it into the standard, it is generally
in a separate package with an implementation-dependent name. On SBCL
this is sb-mop; on CLISP it is mop. I'm not sure where it is on other
implementations. You can find out by scanning the output of (apropos
"MOP").
Here's how to do it in SBCL:
(sb-mop:class-slots (find-class 'baz))
You need the FIND-CLASS call since BAZ is simply a symbol that happens
to be associated with the actual BAZ metaclass object. CLASS-SLOTS
only has a method for metaclass objects.
If this is confusing (or just interesting), you should scrounge around
for The Art of the Metaobject Protocol by Kiczales et al - it's a
really really great read.
--
Bill
From: Bernd Schmitt
Subject: Re: private data hiding via closures?
Date:
Message-ID: <4443CF58.90705@gmx.net>
On 17.04.2006 17:55, Bill Atkins wrote:
> Bernd Schmitt <··················@gmx.net> writes:
>
>> On 17.04.2006 16:47, Pascal Costanza wrote:
>>> Bernd Schmitt wrote:
>>>> On 16.04.2006 23:03, Pascal Costanza wrote:
>>>>> Rainer Joswig wrote:
>>>>>> In article <·························@news.freenet.de>,
>>>>>> Bernd Schmitt <··················@gmx.net> wrote:
>>>>>> Another way to hide data is to use uninterned symbols and CLOS.
>>>>> (mapcar #'slot-definition-name
>>>>> (class-slots (class-of object)))
> Here's how to do it in SBCL:
> (sb-mop:class-slots (find-class 'baz))
>
> You need the FIND-CLASS call since BAZ is simply a symbol that happens
> to be associated with the actual BAZ metaclass object. CLASS-SLOTS
> only has a method for metaclass objects.
CL-USER> (lisp-implementation-type)
"CMU Common Lisp"
CL-USER> (lisp-implementation-version)
"Snapshot 2005-11 (19C)"
CL-USER> (apropos "MOP")
SWANK::MOP-HELPER [function] (class-name fn)
SWANK:MOP [function] (type symbol-name)
:SWANK-MOP [constant] value: :SWANK-MOP
SWANK-BACKEND::IMPORT-SWANK-MOP-SYMBOLS
[function] (package except)
SWANK-BACKEND::IMPORT-TO-SWANK-MOP [function] (symbol-list)
; No value
trying
(mapcar #'mop:slot-definition-name
(mop:class-slots (class-of ii)))
i get
(#:FOO)
how can i change this slot?
Thanks ...
Bernd
--
https://gna.org/projects/mipisti - (microscope) picture stitching
T_a_k_e__c_a_r_e__o_f__y_o_u_r__R_I_G_H_T_S.
P_r_e_v_e_n_t__L_O_G_I_C--P_A_T_E_N_T_S
http://www.ffii.org, http://www.nosoftwarepatents.org
In article <··············@gmx.net>,
Bernd Schmitt <··················@gmx.net> wrote:
> On 17.04.2006 17:55, Bill Atkins wrote:
> > Bernd Schmitt <··················@gmx.net> writes:
> >
> >> On 17.04.2006 16:47, Pascal Costanza wrote:
> >>> Bernd Schmitt wrote:
> >>>> On 16.04.2006 23:03, Pascal Costanza wrote:
> >>>>> Rainer Joswig wrote:
> >>>>>> In article <·························@news.freenet.de>,
> >>>>>> Bernd Schmitt <··················@gmx.net> wrote:
> >>>>>> Another way to hide data is to use uninterned symbols and CLOS.
> >>>>> (mapcar #'slot-definition-name
> >>>>> (class-slots (class-of object)))
>
>
> > Here's how to do it in SBCL:
> > (sb-mop:class-slots (find-class 'baz))
> >
> > You need the FIND-CLASS call since BAZ is simply a symbol that happens
> > to be associated with the actual BAZ metaclass object. CLASS-SLOTS
> > only has a method for metaclass objects.
>
> CL-USER> (lisp-implementation-type)
> "CMU Common Lisp"
> CL-USER> (lisp-implementation-version)
> "Snapshot 2005-11 (19C)"
>
> CL-USER> (apropos "MOP")
> SWANK::MOP-HELPER [function] (class-name fn)
> SWANK:MOP [function] (type symbol-name)
> :SWANK-MOP [constant] value: :SWANK-MOP
> SWANK-BACKEND::IMPORT-SWANK-MOP-SYMBOLS
> [function] (package except)
> SWANK-BACKEND::IMPORT-TO-SWANK-MOP [function] (symbol-list)
> ; No value
>
> trying
>
> (mapcar #'mop:slot-definition-name
> (mop:class-slots (class-of ii)))
>
> i get
>
> (#:FOO)
>
> how can i change this slot?
>
>
> Thanks ...
> Bernd
Once you have the name you can do
(setf (slot-value my-instance name) 100)
Probably by (untested):
(setf (slot-value ii (first (mapcar #'mop:slot-definition-name
(mop:class-slots (class-of ii)))))
100)
--
http://lispm.dyndns.org/
Bernd Schmitt wrote:
> On 17.04.2006 16:47, Pascal Costanza wrote:
>> Bernd Schmitt wrote:
>>> On 16.04.2006 23:03, Pascal Costanza wrote:
>>>> Rainer Joswig wrote:
>>>>> In article <·························@news.freenet.de>,
>>>>> Bernd Schmitt <··················@gmx.net> wrote:
>
>>>>> Another way to hide data is to use uninterned symbols and CLOS.
>>>> (mapcar #'slot-definition-name
>>>> (class-slots (class-of object)))
> trying
>
> (class-slots 'baz)
>
> (with 'baz baz i1 'i1 (i have created i1 on toplevel)) I get an error:
>
> "Error in KERNEL:%COERCE-TO-FUNCTION: the function CLASS-SLOTS is
> undefined.
> [Condition of type UNDEFINED-FUNCTION]"
The CLOS MOP is not part of ANSI Common Lisp. So you have to see in
which packages those functions are interned. Typical names for the CLOS
MOP package are CLOS, MOP, SB-MOP, CLOS-MOP, etc.
>> This means that even if you use an uninterned symbol as the name of a
>> slot, you can still determine that name by iterating through all slots
>> of a class and get their names via the code above.
> Ok, I maybe used class-slots wrong, but even if i can figure out the
> slots of a class/object - one can neither read nor change a slot from
> outside its accessors if it is not interned, right (IIUC) or false?
No, for accessing a slot, it's not important whether the name is an
interned or an uninterned symbol. As long as you have a hold on such a
symbol, you can access the slot...
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
On 17.04.2006 17:50, Pascal Costanza wrote:
> Bernd Schmitt wrote:
>> On 17.04.2006 16:47, Pascal Costanza wrote:
>>> Bernd Schmitt wrote:
>>>> On 16.04.2006 23:03, Pascal Costanza wrote:
>>>>> Rainer Joswig wrote:
>>>>>> In article <·························@news.freenet.de>,
>>>>>> Bernd Schmitt <··················@gmx.net> wrote:
>> Ok, I maybe used class-slots wrong, but even if i can figure out the
>> slots of a class/object - one can neither read nor change a slot from
>> outside its accessors if it is not interned, right (IIUC) or false?
>
> No, for accessing a slot, it's not important whether the name is an
> interned or an uninterned symbol. As long as you have a hold on such a
> symbol, you can access the slot...
Hm. Sorry, but I missed the point.
Suppose I figure out the name of the not interned slot.
How do I read/change its value?
(defclass baz ()
((#:foo :reader baz-foo :initform 1)))
(setf ii (make-instance 'baz))
(slot-value i1 '#:foo)
does not work.
Is this what you tried to tell me, when talking of (class-slots
some-class), (slot-definition-name some-slot)?
Thanks ...
Bernd
--
https://gna.org/projects/mipisti - (microscope) picture stitching
T_a_k_e__c_a_r_e__o_f__y_o_u_r__R_I_G_H_T_S.
P_r_e_v_e_n_t__L_O_G_I_C--P_A_T_E_N_T_S
http://www.ffii.org, http://www.nosoftwarepatents.org
From: Marco Baringer
Subject: Re: private data hiding via closures?
Date:
Message-ID: <m2mzek9n0s.fsf@bese.it>
Bernd Schmitt <··················@gmx.net> writes:
> (defclass baz ()
> ((#:foo :reader baz-foo :initform 1)))
>
> (setf ii (make-instance 'baz))
>
> (slot-value i1 '#:foo)
CL-USER> (defclass baz () ((#:foo :initform 1)))
#<STANDARD-CLASS BAZ>
CL-USER> (defvar ii (make-instance 'baz))
II
CL-USER> (class-slots (class-of ii))
(#<STANDARD-EFFECTIVE-SLOT-DEFINITION for instance slot #:FOO #x8481166>)
CL-USER> (mapcar #'slot-definition-name *)
(#:FOO)
CL-USER> (slot-value ii (first *))
1
CL-USER> (setf (slot-value ii (first **)) 42)
42
CL-USER> (slot-value ii (first ***))
42
CL-USER>
notice that i only passed the string "#:foo" to the reader once, so
only one symbol was created. in your example above you created two
symbols (which happened to have the same name but were distinct
symbols).
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Bernd Schmitt wrote:
> On 17.04.2006 17:50, Pascal Costanza wrote:
>> Bernd Schmitt wrote:
>>> On 17.04.2006 16:47, Pascal Costanza wrote:
>>>> Bernd Schmitt wrote:
>>>>> On 16.04.2006 23:03, Pascal Costanza wrote:
>>>>>> Rainer Joswig wrote:
>>>>>>> In article <·························@news.freenet.de>,
>>>>>>> Bernd Schmitt <··················@gmx.net> wrote:
>
>>> Ok, I maybe used class-slots wrong, but even if i can figure out the
>>> slots of a class/object - one can neither read nor change a slot from
>>> outside its accessors if it is not interned, right (IIUC) or false?
>> No, for accessing a slot, it's not important whether the name is an
>> interned or an uninterned symbol. As long as you have a hold on such a
>> symbol, you can access the slot...
> Hm. Sorry, but I missed the point.
> Suppose I figure out the name of the not interned slot.
> How do I read/change its value?
>
> (defclass baz ()
> ((#:foo :reader baz-foo :initform 1)))
>
> (setf ii (make-instance 'baz))
>
> (slot-value i1 '#:foo)
>
> does not work.
>
> Is this what you tried to tell me, when talking of (class-slots
> some-class), (slot-definition-name some-slot)?
No. Functions like class-slots and slot-definition-name are there to
tell you details about existing class definitions. They are part of the
introspective capabilities of the CLOS metaobject protocol. A very
simple example is class-name which gives you the name of a class. A more
interesting example is class-direct-superclasses which gives you the
list of direct superclasses of a class. Try this:
(defclass a () ())
(defclass b () ())
(defclass c (a b) ())
(class-direct-superclasses (find-class 'c))
These introspective functions tell you quite a lot about your classes,
for example the names of your slots. Here is a sample session:
CL-USER 1 > (use-package :clos)
T
CL-USER 2 > (defclass person ()
((name :initarg :name
:reader name)
(#:ssn :initarg :ssn
:reader social-security-number)))
#<STANDARD-CLASS PERSON 10FAF093>
CL-USER 3 > (defparameter *pascal*
(make-instance 'person :name "Pascal" :ssn 4711))
*PASCAL*
CL-USER 4 > (name *pascal*)
"Pascal"
CL-USER 5 > (social-security-number *pascal*)
4711
So far so good: You have defined a class, together with some readers.
Since you have provided an uninterned symbol as the name for the social
security number, you think you have built in enough provisions so that
noone can harm your code.
However, the introspective functions allow you to access the slot names:
CL-USER 6 > (loop for slot in (class-slots (find-class 'person)) do
(print (slot-definition-name slot)))
NAME
#:SSN
NIL
Note that the second slot name printed (#:SSN) is the original name you
have given that slot in the class definition. It is not generated anew
every time you access the name of that slot via slot-definition-name.
(Why should it?)
So if you are a malicious programmer, you can, for example, blindly
override slots:
CL-USER 7 > (loop for slot in (class-slots (find-class 'person)) do
(setf (slot-value
*pascal*
(slot-definition-name slot))
'screw-you))
NIL
CL-USER 8 > (name *pascal*)
SCREW-YOU
CL-USER 9 > (social-security-number *pascal*)
SCREW-YOU
Clearer?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
On 17.04.2006 21:34, Pascal Costanza wrote:
> Note that the second slot name printed (#:SSN) is the original name
> you have given that slot in the class definition. It is not generated
> anew every time you access the name of that slot via
> slot-definition-name. (Why should it?)
That was my misunderstanding ...
> Clearer?
Yes, thank you very much for your effort to make this clear.
My problem was again the C/C++ view... (names, places, symbols)
Thanks
Bernd
On 16.04.2006 22:19, Rainer Joswig wrote:
> In article <·························@news.freenet.de>,
> Bernd Schmitt <··················@gmx.net> wrote:
>
> Another way to hide data is to use uninterned symbols and CLOS.
>
>
> For example:
>
>
> (defclass baz ()
> ((#:foo :reader baz-foo :initform 1)))
>
> CL-USER 31 > (let ((i1 (make-instance 'baz)))
> (print (baz-foo i1))
> (print (slot-value i1 '#:foo)))
>
> 1
> Error: The slot #:FOO is missing from #<BAZ 100CD287> (of class #<STANDARD-CLASS BAZ 10BE7863>), when reading the value.
> 1 (abort) Return to level 0.
> 2 Return to top loop level 0.
>
> Type :b for backtrace, :c <option number> to proceed, or :? for other options
>
>
>
> Here we can restrict slot-access to a predefined reader function.
> The reader function can access the slot. Using SLOT-VALUE and
> (SETF SLOT-VALUE) is no longer possible (unless somebody can
> provide the uninterned symbol to these functions, which usually
> is unlikely).
Thanks, perfect, that is exactly what I was heading for (CLOS & private
data) as next step. I am currently reading "Successful Lisp" - this kind
of uninterned symbols is not mentioned there. I also have "Paradigms of
Aritificial Intelligence Programming", "Practical CL" and "CL A Gentle
Introduction to Symbolic Computation" available - do you know which of
those covers/explains hiding data?
Thanks,
Bernd
--
https://gna.org/projects/mipisti - (microscope) picture stitching
T_a_k_e__c_a_r_e__o_f__y_o_u_r__R_I_G_H_T_S.
P_r_e_v_e_n_t__L_O_G_I_C--P_A_T_E_N_T_S
http://www.ffii.org, http://www.nosoftwarepatents.org
Bernd Schmitt wrote:
> Hello,
> I restart learning Lisp, so maybe this is FAQ, but I did not find any
> apropriate information. If there is one, please give me a hint where/how
> to find informations like this.
> AFAIK I believe that some data has to be hidden for security reasons
> (passwords, private keys ...).
For proper security analysis you need to specify the types of attacks
you want to defend against, what information you are protecting and
what you want to do with this sensitive information.
Also, it might help us understand the scenario better if you can give
an example of how another environment provides acceptable security when
it is handling similar sensitive data.
For example *nix (unix, linux, etc) attemp to provide password security
in a variety of ways:
* using a one way password function so unencrypted passwords are not
stored.
* using setuid and file system permissions to protect the shadow
password file.
On 18.04.2006 00:48, funkyj wrote:
> Bernd Schmitt wrote:
>> Hello, I restart learning Lisp, so maybe this is FAQ, but I did not
>> find any apropriate information. If there is one, please give me a
>> hint where/how to find informations like this. AFAIK I believe that
>> some data has to be hidden for security reasons (passwords, private
>> keys ...).
>
> For proper security analysis you need to specify the types of attacks
> you want to defend against, what information you are protecting and
> what you want to do with this sensitive information.
I am just a hobby-coder who (again) tries to learn Lisp. I was/am
curious how private data can be achieved (like in C++ private). I was
wondering what kind of defense/offense can be done in Lisp.
> Also, it might help us understand the scenario better if you can give
> an example of how another environment provides acceptable security
> when it is handling similar sensitive data.
I am sorry that I can not give you an appropriate answer on this (maybe
using/storing private keys / symmetric keys). I was wondering about the
use of libraries and basic security issues. Like arguments for a
(theoretical) discussion about security risks of Lisp-applications. I
just would like to inform myself about issues I am not sure about.
Sorry
Bernd
Bernd Schmitt <··················@gmx.net> writes:
> On 18.04.2006 00:48, funkyj wrote:
>> Bernd Schmitt wrote:
>>> Hello, I restart learning Lisp, so maybe this is FAQ, but I did not
>>> find any apropriate information. If there is one, please give me a
>>> hint where/how to find informations like this. AFAIK I believe that
>>> some data has to be hidden for security reasons (passwords, private
>>> keys ...).
>>
>> For proper security analysis you need to specify the types of attacks
>> you want to defend against, what information you are protecting and
>> what you want to do with this sensitive information.
> I am just a hobby-coder who (again) tries to learn Lisp. I was/am
> curious how private data can be achieved (like in C++ private). I was
> wondering what kind of defense/offense can be done in Lisp.
What use is private?
extern "C"{
#include <stdio.h>
}
class test{
private:
int n;
public:
test(int _n){
printf("%d\n",((char*)&(this->n))-((char*)this));
n=_n;}
virtual void f(void);
};
void test::f(void){
printf("this n is %d\n",n);}
int main(void){
test* o=new test(1);
o->f();
((int*)o)[1]=2;
o->f();
return(0);}
g++ -o a a.c++ && ./a
4
this n is 1
this n is 2
>> Also, it might help us understand the scenario better if you can give
>> an example of how another environment provides acceptable security
>> when it is handling similar sensitive data.
> I am sorry that I can not give you an appropriate answer on this (maybe
> using/storing private keys / symmetric keys). I was wondering about the
> use of libraries and basic security issues. Like arguments for a
> (theoretical) discussion about security risks of Lisp-applications. I
> just would like to inform myself about issues I am not sure about.
Well, in CL you have the basic security (actually it's
implementation dependant, but it's expected and provided in general)
that array bounds are checked and that there's no user manipulable
pointer. What more do you want?
In SYSTEM packages, anything can happen: you're not less free in CL
than in C++.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
Bernd Schmitt wrote:
> On 18.04.2006 00:48, funkyj wrote:
> > For proper security analysis you need to specify the types of attacks
> > you want to defend against, what information you are protecting and
> > what you want to do with this sensitive information.
> I am just a hobby-coder who (again) tries to learn Lisp. I was/am
> curious how private data can be achieved (like in C++ private). I was
> wondering what kind of defense/offense can be done in Lisp.
>
>
> > Also, it might help us understand the scenario better if you can give
> > an example of how another environment provides acceptable security
> > when it is handling similar sensitive data.
> I am sorry that I can not give you an appropriate answer on this (maybe
> using/storing private keys / symmetric keys). I was wondering about the
> use of libraries and basic security issues. Like arguments for a
> (theoretical) discussion about security risks of Lisp-applications. I
> just would like to inform myself about issues I am not sure about.
You have provided plenty of information. If we are simply comparing
the security provided by C++'s "private" keyword then your security
model is this:
The "private" keyword seeks to keep the programmer that is
writing C++ code from shooting himself in the foot. It is does
not provide any protection against malicious hackers trying
to subvert a program or operating system.
With a C/C++ program the user can run it under a debugger (assembly
level debugging without C source). It is typically the OS that must
provide security primitives (e.g. setuid bit etc) and the software
architect must design a secure system.
I guess if you are interested in the "keep the lazy malicious hackers
out" type of security (e.g. JVM byte code obfuscation provides this
level of security) there might be a lot of techniques that could be
applied to lisp.
So, here are some categories for you to think about regarding security:
* help protect the software engineer from himself
(e.g. C++ private keyword) this isn't really security as it doesn't do
much to prevent malicious hacking.
* weak proprietary encapsulation.
Example, you provide documentation and a binary library of C++
functions but no source code. Industrious hackers can still step
through your library's using a low level debugger and figure out the
internals. Again, this doesn't provide any real "security" against
malicious hackers. Instead, like the lock on the door of your house or
car, it keeps the honest folk out. This is a type of "security through
obscurity".
* real security. I'll let others break this large domain into smaller
pieces.
While you may be interested in the theoretical aspects, it is still
best to have a scenario as the basis for your discussion.
For example, if you read Bruce Schneier's _Applied_Cryptography_ he
discusses the basic threats against a secure crypto channel by
describing various scenarios (brute force, chosen plain text, man in
the middle). In those discussions he makes it clear that he is not
addressing how the communication might be compromised before it becomes
encrypted and is transmitted (e.g. a virus instals a keystroke logger
than reveals your encryption key to the attacker).
Here is a discussion topic if you are interested in "real security":
consider the program PGP or GPG. What types of threats does PGP
protect against? What types of threats does PGP not protect against?
Could you make PGP more secure by implementing it in LISP, OCaml,
Python, Perl or Java? Why or why not?
For most systems (windows, linux, mac) I think the general consensus is
that if you give a malicious hacker access to your machine (i.e. she
can run programs in the debugger and she can install her own programs)
it is game over.
A while back there were attempts to provide restricted interpreters for
TCL and other languages so that applets using this language could run
untrusted scripts but it appear that folks have given up on this
approach.
> Sorry
> Bernd
No need to apologise.
Bernd Schmitt wrote:
> AFAIK I believe that some data has to be hidden for security reasons
> (passwords, private keys ...).
This type of security concern has nothing to do with information hiding
in a programming language. It's a platform issue. It can be a
programming language issue if the programming language is the platform.
E.g. in a purely Lisp-based operating system with no hardware memory
protection, who can see what is determined by what objects they have
access to. Subverting the machine to run arbitrary code and access
arbitrary memory locations can only be done by a superuser, who can
request to compile and execute untrusted code. Such a system would give
you no back door to peek at the contents of a closure directly, so your
only access mechanism would be the closure bodies.
In a conventional OS, you are relying on address space protection, and
certain features of the OS: the ability to nail down pages so they are
not swapped out, and the scrambling of discarded memory frames before
they are recycled to another process.
Consider what would happen if a function like mmap() didn't zero-out a
frame of memory before doling it out to a process. One process could
liberate some area that holds a password, and that page would appear in
a newly allocated page in another process.
Swapping is also a concern. If a frame of memory containing sensitive
information is swapped out to disk, there is the risk that it will
endure in the swap area.
And of course, if someone hacks a privileged account, they can just
look at the memory image of any process.
Security-sensitive code has to be carefully written, to use the
platform hooks to prevent swapping. The security middleware itself
should take the responsibility of scrambling the memory before
liberating it, rather than relying on the system to do that. The
duration of the sensitive information is kept short. That is not always
possible; some types of applications have to cache authentication
tokens for long periods so that they can answer authentication requests
(e.g. ssh-agent and similar software).
> I wonder if data-hiding can be done with closures.
Protection of sensitive data can be done
> How can one access data inside a closure from outside?
>
> ? (let ((e 1))
> (defun closure-1 () e))
> CLOSURE-1
> ? (closure-1)
> 1
> ? e
> Error: unbound variable
>
> I mean, is it possible to change the value of the e in closure-1 from
> outside?
If your Lisp system allows the execution of arbitrary code, then
anything is possible. Consider that most CL impementations let you call
foreign functions. A foreign function written in C can look at any
memory it wants. So all code within a Lisp image is implicitly trusted.
If you want the language to provide security, then the implementation
has to be proofed against this sort of thing. There have to be
authentication mechanisms in place for loading and running code, and
for the use of escape hatches in the interpreter and compiler.