+++ /dev/null
-#####################################################################
-#####################################################################
-#####################################################################
-######## mod_vhost_ldap version 2.0.3 or later ######################
-#####################################################################
-
- This file contains further considerations and usage examples
-of single-value access control entry attribute named
-"apacheExtConfigRequireValidUser". Handling of user "validity" is
-quite complicated and a little bit different than you could expect,
-so even I make sometimes misunderstanding if its current implemen-
-tation if this feature.
-
-I'm going to explain here, how user validity is related to
-TWO types of resources, to which access control may be defined:
-
-I. Location access control (sometimes referred as uri access control,
-or virtual host access control)
-II. Directory access control (sometimes referred as physical location
-access control, or virtualhost-independent access control).
-
-Resource, depending on case, may mean "location" or "directory",
-or "both/no matter which kind of goods" :-).
-
-"Access control" usually means authentication + authorization (for
-polish readers - "uwierzytelnianie" and "autoryzacja").
-
-Authentication concerns about various ways of checking validity
-of username/password pair. It includes checking whether user
-exists in user-information source, and whether supplied password
-is valid for supplied user. There are hundreds of methods to
-perform such tasks and apache supports many of them. However,
-mod_vhost_ldap currently support ONLY "basic" authentication,
-which conforms to checking whether user exists and whether applied
-password is correct for applied username. Some authentication
-methods may be used for authentication and authorization, some
-of them cannot (in some situation some information e.g. "realm"
-provided by clients with authentication are used to authorize
-them, sometimes not), however with modvhostldap authentication
-and authorization are two different things.
-
-Authorization concerns about checking whether particular user is
-authorized to connect/use particular resource or particular
-kind of resource.Depending on authorization configuration,
-a resource may be available only to authenticated users, or
-for authenticated and not-authenticated users. Here we
-take care only about resources which are available only for
-authenticated users, so every not-authenticated user is not
-authorized to access particular resources. We don't discuss
-resources that don't need users to be authenticated to determine
-whether they're authorized or not, and vice versa - we assume,
-that every resource which has authentication defined, has
-user authorization status determined in some way, which will
-be explained below.
-
-Authentication is most simple of all of this - authenticated
-user is a user which provided username and password, and
-the pair was verified in some way. Http authentication status
-information is then kept in http headers (usually until
-browser or browser-window is not reopened, depending on browser.
-
-First we define what's actually defined by access control entry,
-and what is NOT defined by access control entry.
-
-In both cases, (location and directory) access control entry
-defines whether particular resource is protected, however
-with directory, existing access entry means that directory
-has access control, and for location, existing access entry
-means,that location is protected if and only if virtual host
-has access control enabled. you can enable/disable location access
-control for virtualhost, no matter whether access control
-entry for this location exists - on virtual host configuration
-level, by setting apacheExtConfigHasRequireLine attribute to
-TRUE or FALSE. if this attribute for vhost is FALSE, location
-access control won't be checked at all.
-Directory access control is always checked, no matter, whether
-virtualhost has access control enabled, or not. LAC is configured
-against particular address on (with) particular virtual server, DAC
-is configured against physical location of the resource, no matter
-whether it is accessed by some alias address, or some uri
-directly available under virtual server directory tree. (www.internal.com/ and below).
-Sometimes you may want particular file or directory
-on the disk to be protected, no matter which way user tries
-to access it, and sometimes you may want that some particular
-URL to be protected, if its accessed via www.domain.com, but
-opened e.g. from internal network (when it's accessed via www.inernal.com
-virtualhost, which is available for internally-conected clients.
-
-Directory access control has higher level of importance than
-location access control. Secured directory is secured no matter
-under which location it's accessed. If you secure directory
-as directory, and you secure location, location authentication
-and authorization will be checked first, and if allowed, directory
-authentication and authorization will be checked, and if
-denied - user will be denied access. Authentication information
-are stored somewhere in http headers, so once authenticated
-user data will be passed to directory authentication.
-if the same user is authorized to access directory, access
-will be granted, if perlocation-authenticated user is not
-authorized to access directory, a prompt for another
-authentication data will be displayed. This may cause
-to annoying results, as authentication information in http
-headers would be probably replaced (?), and new values won't
-match location requirements. However i'm not sure how this
-works, I didn't tested it, it's possible that headers may contain
-information for location and directory, anyway it's recommended to
-avoiding such situation, to always have clearance which set of access
-control settings are applied to the resource client wants access.
-In doubt I suggest you to configure per-directory access control,
-in almost all cases this is what you want.
-
-
-
-Now, for apache there are three ways in which user can be
-authorized for resource: user may be valid-user, user may
-be one of exactly defined authorized users, or user may
-be member of authorized group. for details refer to apache documentation
-of "Require" directives, anyway, modvhostldap currently
-supports valid-user and userlist, and this is difference,
-which is determined by apacheExtConfigRequireValidUser attribute.
-
-Location "Require" directive is created for
-each request for each vhost which have has LAC enabled
-(hasRequireLines = TRUE), and for which there's found
-access control object, which has the same or higher
-uri as its apacheExtConfigUri value.
-
-Directory Require directive is created
-if there's found access control object, which has
-the same or higher directory as its apacheExtConfigPath value.
-
-Let's assume that if we're processing per-location config
-then servername of the http request is "internal", and uri of the
-request is "/abcd/xyz/protected/" (so we have
-http://internal/abcd/protected/xyz/"
-First is checked whether "internal" HasRequireLines is TRUE.
-If yes, then there's made a lookup for access control
-entry, which has apacheExtConfigServerName value = internal
-and apacheExtConfigUri value set to a value,
-which is contained in '/abcd/protected/xyz' starting
-from left. so access control objects which have
-apacheExtConfigUri like: "/", "/abc",
-"/abcd/xyz/protected" and "/abcd/xyz/protected/"
-will match. Finally, if the full string is reached,
-and access control object is not found, error is
-reported - (access control configured but no
-access control objects found), and access control
-is not applied.
-
-And - other case - if we're processing per-directory config,
-then match is made exactly the same way, except that
-servername is not checked. If higher (shorter) or equal
-directory value has acl object with this value - object
-is matched. If full string is reached and object is not found,
-access control is not applied, and no error is reported.
-
-Now ACL object, if found, is examined.
-If apacheExtConfigRequireValidUser attribute for it
-has value set to "TRUE", then
-configuration is processed as "Require valid-user"
-(access shoud be granted to any valid user).
-analog directive,
-If it's "FALSE", then configuration
-is processed as "Require user ..." directive, userlist
-is created, and access is granted to any valid user,
-which username is on the list.
-List, if needed, is created depending on values
-of attribute apacheExtConfigUserDn which must in this
-case contain full distinguished names of the users,
-which should have access granted. Username "nobody"
-is always appended first, before appending attribute
-values (loginnames), to avoid situation, when
-apacheExtConfigRequireValidUser = FALSE, and no apacheExtConfigUserDn
-values exist in entry ("Require user" if defined, must contain at least one username).
-
-So access gets configured, and then it comes to authentication.
-Further processing depends whether it's case I or II.
-In case I - valid user, is user which matches the following filter:
-(&
- (_D_)
- (objectClass=apacheExtendedConfigUserObject)
- (apacheExtConfigUserServerName=_A_)
- (apacheExtConfigUserLocationUri=_G_)
-)
-
-and in case II
-(&
- (_D_)
- (objectClass=apacheExtendedConfigUserObject)
- (apacheExtConfigUserDirectoryName=_E_)
-)
-
-where _D_ is global user-defined filter, and other attributes
-have values the same as access control object.
-More details about used filters and global
-user-defined filter you'll find in vhost_ldap.conf
-
-Finally, in both cases, if access control object
-has apacheExtConfigRequireValidUser = FALSE, user is authenticated,
-loginname is found on the list, access is granted, or
-of the apacheExtConfigRequireValidUser = TRUE,and user is authenticated,
-access is granted, otherwise access is denied.
-This final stage, in comparison to analog configuration files,
-is the same as checking context in which particular user has been
-defined - <Directory /some/dir> or <Location /abcd/xyz/protected>.
-Simply - with .htaccess context is determined based on
-the location of the .htaccess file, in common configuration
-context is determined by the context :-), and with ldap
-context is determined by attributes of the particular webuser.
-
-For each user object, supplied password is checked against
-as clear text, htpasswd format, or unix crypt format, and with
-debug all of them are logged, and additionaly. information
-which one matched (or none) is logged too.
-
-So, to be short at last - access control has particular precendence,
-there are some differences between location and directory access
-processing. You always need to specify inside userobject
-for which resource it is valid, and, additionaly, if you set
-apacheExtConfigRequireValidUser=FALSE, then you need to
-put webuser object DN into apacheExtConfigUserDn attribute
-of the access entry related to this resource. Applied
-password is checked against mostly used formats.
-And, you can have multiple locations, directories and servernames
-for access config entries, and user entries, and (ugh),
-you can have multiple access control entries for virtualhost(s).
-
-If you get into mess, and things doesn't work, you can disable
-some part(s) of authentication process. any trouble with
-authentication won't impact rest of virtualhost filesystem.
-Aliased directiories are substituted first, so directory
-access control entries will apply only to final real-directory
-or file name.
-
-Aliasing match works similar way as Directory and Location
-match - there's a try to find object which define targed physical
-location for current URI, and this target (existing or not),
-has precedence over (existing or not) URL part(s).
-And you can have multiple aliases for virtualhost, and
-multiple virtual URI's for one target.
-
-If you create entries, which coincidents, like two
-alias object which specify the same url and vhost, but
-different targets, or two uses with the same
-logins and the same permissions but e.g. different passwords,
-only first found will be used (each matching is done only once),
-and it's hard to predict which one this would actually be.
-Creating users without passwords at all, is avoided by
-schema.
-
-Note, that all this stuff is of course checked before actual
-resource is returned to browser, so any of alias targets, or
-users defined as valid, doesn't need to be existing - if
-they don't exist, finally some HTTP error will be returned, but
-existence of objects doesn't affect processing itself.
-
-Have fun, feedback welcomed :)
-PW.
\ No newline at end of file
+++ /dev/null
-##########################################################################################
-##########################################################################################
-############# SKIP COMMENTED LINES TO SEE PURE LDIF FILE #################################
-##########################################################################################
-############# If particular access combination of pattern #######################
-############# [([location+servername]|[directoryname])+username]) #######################
-############# does not work, first consult actually used filters #######################
-############# presented in example vhost_ldap.conf, and then turn #######################
-############# debugging logging with apache. there's very much log #######################
-############# output, including configuration and uri parsing #######################
-############# and each search filter and retrieved variables #######################
-############# processing. #######################
-##########################################################################################
-##########################################################################################
-
-##### webserver definition
-dn: apacheServerName=internal,ou=virtualHosts,dc=foo,dc=bar
-objectClass: top
-objectClass: apacheConfig
-objectClass: organization
-##### object classess - for aliases and per-location auth
-##### you must include these
-objectClass: apacheExtendedConfigLocation
-objectClass: apacheAliasesConfigLocation
-o: apache
-apacheServerName: internal
-##### single-value
-apacheDocumentRoot: /var/www/internal
-##### multi-value (optional)
-apacheServerAlias: www.somedomain.com
-apacheServerAlias: www.internal
-##### whether aliases objects search should be performed
-##### for requests to this host (aliases are assigned
-##### to webserver and its uri name (virtual location)
-##### with this you can keep pointers to config objects assigned,
-##### but turn them off for vhost - if you set next two attrs
-##### to FALSE, location and aliases won't be searched for it,
-##### althoug *OptionsDn exists
-apacheAliasesConfigEnabled: TRUE
-apacheExtConfigHasRequireLine: TRUE
-##### next two are multi values, which mean you can define
-##### many aliases and many protected location for vhost
-apacheAliasConfigOptionsDn: apacheAliasConfigObjectName=internal vhost alias one,ou=webAliases,dc=foo,dc=bar
-apacheLocationOptionsDn: apacheExtConfigObjectName=internal vhost access control,ou=webAccess,dc=foo,dc=bar
-
-##### heads up - access control configuration object
-dn: apacheExtConfigObjectName=internal vhost access control,ou=webAccess,dc=foo,dc=bar
-objectClass: organization
-objectClass: top
-##### required to work
-objectClass: apacheExtendedConfigObject
-o: apache
-##### next attribute determines whether this
-##### configuration objects is of type "require valid-user" (TRUE)
-##### or "Require user1 user2 user3". This is actually related
-##### for user object search. if you set to true, lookup will
-##### search for userobjects which are under WucBaseDn
-##### and have userobjectservername set to alias or servername
-##### of current vhost, if you set to false, apacheExtConfigUserDn
-##### will be processed to get userlist ("Require user1,user2,user3...")
-##### Require group usergroup not implemented yet
-apacheExtConfigRequireValidUser: TRUE
-##### this is usually naming attribute in the tree, anyway
-##### this is the value which appears in http auth prompt dialog
-apacheExtConfigObjectName: internal vhost access control
-##### now - in this example, this access object keep access config
-##### of two kinds, per-location and per-directory. Next two
-##### attributes specified per-location assignment - perlocation
-##### access control will search for object which has current req servername
-##### and current req Uri. It is planned to be able to specify regexp
-##### as configUri and configPath, however it's not implemented yet.
-apacheExtConfigServerName: internal
-apacheExtConfigUri: /locationprotected
-apacheExtConfigPath: /var/www/internal/protected
-##### and one above is searched for every request, compared to request r->filename,
-##### no matter what's current vhost servername is.
-##### You can have any combination of these three lines including none of them.
-##### this object in general actually determines authorized users for resource,
-##### so you can have some userlist specification for many servernames and aliases,
-##### many uris (locations), and for many directories in the same object.
-##### you should only remember, that for perlocation access config
-##### servername/serveralias AND extConfigUri is matched, and for perdirectory
-##### only extConfigPath is searched.
-##### and the last piece of the puzzle - if requirevaliduser is set to TRUE
-##### (meaning access control entry of type "Require valid-user" and any
-##### userobject which have servername and uri assigned is accepted
-##### if requirevaliduser is set to FALSE, (the meaning is:
-##### "<this acl objectis NOT "Require valid-user">, which actually equals to:
-##### <this acl object is "Require user1 user2 user3">)
-##### list of attribute values for the following directive is processed.
-apacheExtConfigUserDn: apacheExtConfigUserName=pwadas,ou=People,dc=foo,dc=bar
-apacheExtConfigUserDn: apacheExtConfigUserName=otherUser,ou=People,dc=foo,dc=bar
-##### and, of course, you can have multiple values for this attribute
-##### (final list contains multiple usernames). Remember - username "nobody" is
-##### a special username, which is always appended to the result list, to avoid
-##### case, when you specify extConfigRequireValidUser to FALSE and do not specify
-##### any usernames (valid list <"require user" '[username] ...'> passed to apache
-##### must include at list one username. so creating user object entry
-##### with extConfigUserName "nobody" is not recommended as it's always appended
-##### to the list.
-
-##### username object
-dn: apacheExtConfigUserName=pwadas,ou=People,dc=foo,dc=bar
-##### these object must contain one or more values for UserName attribute.
-##### keeping one value which should be naming attribute is recommended,
-##### however you can specify many loginnames for one user.
-##### If you create two userobject entries, and both of them will have
-##### attribute apacheExtConfigUserName with the value "johnny"
-##### (this may be hidden if UserName is not naming attribute)
-##### password will be matched ONLY against first entry found.
-##### which one will be found first when lookup is done with
-##### "(username=XXX)(servername=YYY)(uri=ZZZ)" is hard to predict,
-##### consult with openldap documentation, and watch the filter used.
-##### on the other hand - you can still have to userobjects with
-##### the same names for per-location access control, and if
-##### these object have different servernames - appropriate one
-##### will be found.
-apacheExtConfigUserName: pwadas
-apacheExtConfigUserName: someotherusername
-o: apache
-objectClass: organization
-objectClass: top
-##### this is required of course
-objectClass: apacheExtendedConfigUserObject
-##### now - you can have multiple passwords for one userobject
-##### no matter how many usernames it contains.
-##### recognized password format is cleartext,
-##### standard htpasswd-encrypted string (stored as cleartext)
-##### and linux-shadowlike value stored as {CRYPT}. This means,
-##### that you can combine posixAccount with webuser object,
-##### if you create object with appropriate classes, and
-##### userPassword attribute is the same for both classes.
-##### however in such situation extendedconfigUserName is
-##### still required and multi-value :-), so you'll probably want
-##### keep posixAccount's "uid" and this have at least one the same value.
-##### of course this applies to any attribute which you map
-##### as "uid" in libnss-ldap configuration. with mod-vhost-ldap
-##### ONLY extConfigUserName is searched.
-userPassword: www
-userPassword: p00nQ0ftSC5cU
-userPassword: {CRYPT}$1$RG.pRvZh$Q0WZ8clsqtMUBRLFckoQg1
-##### one username object may contain multiple values
-##### for URI's and directories. which mean you can apply
-##### the same userobject to many resources. however
-##### with LocationUri, appropriate configUserServername must be
-##### defined to have this userobject matched with search lookup.
-apacheExtConfigUserDirectoryName: /var/www/internal/protected
-apacheExtConfigUserServerName: www.internal
-apacheExtConfigUserLocationUri: /protecteduri/
-
-##### and the most simple thing - aliasing object
-##### ObjectName has only naming usage, if any, as aliases
-##### doesn't have "prompts". however object must have some logical
-##### name, and uri or target is not a good choice - first because
-##### it always contain at least one "/", and second - it can
-##### have many values for sourceUri, so specifying it as naming
-##### attribute will always mask other values.
-dn: apacheAliasConfigObjectName=internal vhost alias one,ou=webAliases,dc=foo,dc=bar
-objectClass: organization
-objectClass: top
-objectClass: apacheAliasConfigObject
-o: apache
-apacheAliasConfigObjectName: internal vhost alias one
-##### you can alias multiple uri's to one physical directory
-apacheAliasConfigSourceUri: /abcd/x
-apacheAliasConfigSourceUri: /some/url/anywhere
-##### remember - for aliases to work, you must specify at least
-##### one servername, as aliases (virtual uri's) are always
-##### related to virtualhost. anyway, if you specify multiple
-##### servername, the result will be the same uri for many
-##### virtualhosts, assigned to the same physical directory.
-##### with multiple servername, the same issues applied
-##### as with multiple loginnames - if it's not naming attribute
-##### you may get messed with many objects describing the same
-##### uri for the same vhost (multiple pairs for uri+servername).
-##### in this case first one found will be returned applied.
-##### (lookup is done in the way which returns ONE entry only).
-##### original mod_alias supports regular expression to specify
-##### this, in modvhostldap regexp is not supported yet.
-##### it's planned to be able to define regexp for servername and uri,
-##### and this will be even more flexible than original, as
-##### with original you can have regexp for uri only, and vhost
-##### is determined by context to which directive AliasMatch apply.
-apacheAliasConfigServerName: internal
-apacheAliasConfigServerName: www.someotherhost.com
-##### target dir is single-value. It could be multiple-value,
-##### to be able to store different pairs with one object, however
-##### on the other hand specifiying two or more physical directories
-##### for one URI doesn't make much sense, so to avoid mess
-##### it's single value.
-apacheAliasConfigTargetDir: /var/www/internal/protected
-##### and that's all folks :)
+++ /dev/null
-index apacheExtConfigServerName pres,eq,sub
-index apacheExtConfigUri pres,eq,sub
-index apacheExtConfigPath pres,eq,sub
-index apacheAliasConfigSourceUri pres,eq,sub
-index apacheAliasConfigTargetDir pres,eq,sub
-index apacheAliasConfigServerName pres,eq,sub
-index apacheDocumentRoot pres,eq
-index apacheExtConfigObjectName pres,eq
-index apacheExtConfigRequireValidUser pres,eq
-index apacheExtConfigUserDn pres,eq
-index apacheExtConfigUserServerName pres,eq
-index apacheLocationOptionsDn pres,eq
-index apacheAliasConfigOptionsDn pres,eq
-index apacheAliasConfigObjectName pres,eq
-index apacheServerAdmin pres,eq
-index apacheServerAlias pres,eq
-index apacheServerName pres,eq
\ No newline at end of file
+++ /dev/null
-#TLSCipherSuite HIGH:MEDIUM:+SSLv3
-#TLSCertificateFile /etc/ldap/TLS/ldapserver.crt
-#TLSCertificateKeyFile /etc/ldap/TLS/ldapserver.key
-#TLSCACertificateFile /etc/ldap/TLS/ca.crt
-
-#allow bind_v2
-disallow bind_anon tls_2_anon
-
-include /etc/ldap/schema/core.schema
-include /etc/ldap/schema/cosine.schema
-include /etc/ldap/schema/nis.schema
-include /etc/ldap/schema/inetorgperson.schema
-include /etc/ldap/schema/misc.schema
-include /etc/ldap/schema/local.schema
-include /etc/ldap/schema/mod_vhost_ldap.schema
-include /etc/ldap/schema/apache_ext.schema
-include /etc/ldap/schema/apache_alias.schema
-
-pidfile /var/run/slapd/slapd.pid
-argsfile /var/run/slapd.args
-modulepath /usr/lib/ldap
-moduleload back_bdb
-backend bdb
-schemacheck on
-
-checkpoint 1 5
-
-#sum values as ldap level
-# 1 trace function calls
-# 2 debug packet handling
-# 4 heavy trace debugging
-# 8 connection management
-# 16 print out packets sent and received
-# 32 search filter processing
-# 64 configuration file processing
-# 128 access control list processing
-# 256 stats log connections/operations/results
-# 512 stats log entries sent
-# 1024 print communication with shell backends
-# 2048 entry parsing
-
-#loglevel 768
-loglevel 0
-
-database bdb
-lastmod on
-suffix "dc=ROOT"
-directory "/var/lib/ldap"
-sizelimit unlimited
-timelimit unlimited
-
-include /etc/ldap/indexes
-
-rootdn "cn=admin,dc=foo,dc=bar"
-
-access to dn.base=""
- by * read
-
-access to *
- by dn="cn=admin,dc=foo,dc=bar"
- by dn="cn=nobody,dc=foo,dc=bar" read
- by * none
+++ /dev/null
-### mod_vhost_ldap depends on mod_ldap ###
-### you have to enable mod_ldap as well ###
-### and probably set various cache options for it ###
-
-###scope values: base, one, sub
-###deref values: never, finding, searching, always
-###remember, user specified filter is checked as RFC-defined ldap filter before substitution
-###user filter specified here results with following internal filters and variables:
-### _A_ is the server name from the request (vhost server name to find)
-### _B_ is the uri for which access control is to be determined
-### _C_ is the name of the require valid-user directive (auth prompt message)
-### _D_ is the the user-defined filter
-### _E_ is the protected physical directory (doesn't need to be existing file or dir)
-### _F_ is the alias location uri
-### _G_ is the protected uri for which access control is to be determined (see _E_)
-### _H_ is the alias uri which is to be aliased to specified directory
-### Each use of search filter is logged with debug level
-
-#####################################################################
-### Vhost search
-### (&(_D_)(|(apacheServerName=_A_)(apacheServerAlias=_A_)))
-#####################################################################
-### Protected Location Search
-### (&(_D_)(apacheExtConfigServerName=_A_)(apacheExtConfigUri=_B_))
-#####################################################################
-### Protected Directory Search
-### (&(_D_)(apacheExtConfigPath=_E_))
-#####################################################################
-### Alias Object Search
-### (&(_D_)(apacheAliasConfigServerName=_A_)(apacheAliasConfigSourceUri=_H_))
-#####################################################################
-### Web user Location Search
-### (&(_D_)(objectClass=apacheExtendedConfigUserObject)(apacheExtConfigUserServerName=_A_)(apacheExtConfigUserLocationUri=_G_))
-#####################################################################
-### Web user Directory Search
-### (&(_D_)(objectClass=apacheExtendedConfigUserObject)(apacheExtConfigUserDirectoryName=_E_))
-##################################
-
-### ldap[si]://host[:port]/basedn[?attrib[?scope[?filter]]]
-
- VhostLdapEnabled On
- VhostLdapUrl ldap[si]://host[:port]/basedn[?attrib[?scope[?filter]]]
- #VhostLdapUrl ldap://hostname:389/dc=foo,dc=bar?*?sub?objectClass=activeObject
- VhostLdapBindDn "cn=read only apache admin,dc=foo,dc=bar"
- VhostLdapBindPw "secretpassword"
- VhostLdapWlcBaseDn "ou=webAccess,dc=foo,dc=bar"
- VhostLdapWucBaseDn "ou=webAccounts,dc=foo,dc=bar"
- VhostLdapAliasesBaseDn "ou=webAliases,dc=foo,dc=bar"
- VhostLdapDeref "never"
- VhostLdapFallback default
- VhostAliasesEnabled On
- VhostLocAuthEnabled On
- VhostDirAuthEnabled On
-
-
andersk / mod-vhost-ldap.git / commitdiff
