Trac is configured with multiple subversion repositories
http://trac.company.com/trac/browser/
REPO1
REPO2
REPO3
Currently staff access this as anonymous. I am adding a new repository UTILITIES that I don't want anonymous users to be able to see.
This is where AuthzPolicy comes in, but I am really struggling to get it working.
In trac.ini I have
[trac]
...
permission_policies = AuthzPolicy,
ReadonlyWikiPolicy,
DefaultPermissionPolicy,
LegacyAttachmentPolicy
[components]
...
tracopt.perm.authz_policy.* = enabled
[authz_policy]
authz_file = /var/trac/conf/authzpolicy.conf
But I am unable to figure out what I need to add in authzpolicy.conf to block BROWSER_VIEW from anonymous. I have tried (various combinations of):
[*]
* = !BROWSER_VIEW
anonymous = !BROWSER_VIEW
[repository:*]
* = !BROWSER_VIEW
anonymous = !BROWSER_VIEW
[repository:UTILITIES*]
* = !BROWSER_VIEW
anonymous = !BROWSER_VIEW
Nothing I seem to add in there, blocks an anonymous user from browsing any repositories. The relevant bits from debug log don't really shed any light either:
2019-09-19 12:33:19,518 Trac[authz_policy] DEBUG: Parsing authz security policy /var/trac/conf/authzpolicy.conf
2019-09-19 12:33:19,519 Trac[authz_policy] DEBUG: Checking BROWSER_VIEW on repository:UTILITIES#*/source:/#68
2019-09-19 12:33:19,521 Trac[authz_policy] DEBUG: Checking BROWSER_VIEW on repository:UTILITIES#*/source:/tags#68
2019-09-19 12:33:19,523 Trac[authz_policy] DEBUG: Checking BROWSER_VIEW on repository:UTILITIES#*/source:/branches#68
2019-09-19 12:33:19,524 Trac[authz_policy] DEBUG: Checking BROWSER_VIEW on repository:UTILITIES#*/source:/trunk#68
...
2019-09-19 12:33:19,628 Trac[authz_policy] DEBUG: Checking CHANGESET_VIEW on repository:UTILITIES#*/changeset:1#*
2019-09-19 12:33:19,636 Trac[authz_policy] DEBUG: Checking CHANGESET_VIEW on repository:UTILITIES#*/changeset:68#*
If I remove BROWSER_VIEW from anonymous in the DefaultPermissionPolicy then nothing can browse repositories, even when I put the following in authzpolicy.conf.
[*]
* = *
The main issue turned out to be permissions on /var/trac/conf/authzpolicy.conf I needed to give the web server read access
$ chgrp apache /var/trac/conf/authzpolicy.conf
$ chmod 640 /var/trac/conf/authzpolicy.conf
Once that issue was resolved I started to see different behaviour based on permissions configured, and finally came up with the following for what I needed
[repository:UTILITIES#*]
john = BROWSER_VIEW
* = !BROWSER_VIEW
[repository:*#*]
john = !BROWSER_VIEW
* = BROWSER_VIEW
John can see UTILITIES but not the other repositories, and anonymous can see all repositories except UTILITIES.
I realise that John can log out and see the other repositories. The main aim was to prevent anonymous users seeing the UTILITIES repository.
Related
I'm setting up a new FreeRADIUS v3.0.20 system (Ubuntu 20.04) and having a problem getting auth requests to go to a separate file. I was successful doing it on my older (v2.2.8) system but am apparently missing something here. I checked the documentation, ran both systems in debug mode, but no luck.
I added the "requests..." line to the log section of /etc/freeradius/3.0/radiusd.conf
log {
destination = files
file = ${logdir}/radius.log
requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log
Requests are being logged to /var/log/freeradius/radius.log:
Wed Sep 22 16:10:11 2021 : Auth: (0) Login OK: [user1] (from client Switches port 0 cli 8.1.1.1)
but I want them in a file similar to "/var/log/freeradius/radiusd-DEFAULT-20210922.log"
Is there something I'm missing in the sites-enables/default file or something else dumb I've missed? Thanks!
We have setup lsyncd to sync data between two hosts. The ssh connection is configured to use user tomcat with the matching id_rsa identity file. For some reason a append/create on the remote works fine, but deleting doesn't work. When rsync tries to delete a file, the root user is used to connect to the destination host and not the tomcat user (which is used for create/append).
In the logs (/var/log/lsyncd/lsyncd.log) we see:
Wed Feb 15 13:48:24 2017 Normal: Rsyncing list
/test.txt
Wed Feb 15 13:48:26 2017 Normal: Finished (list): 0
Wed Feb 15 13:48:34 2017 Normal: Deleting list
/myfolder//test.txt
Received disconnect from 10.29.146.78: 2: Too many authentication failures for root
Wed Feb 15 13:48:41 2017 Normal: Retrying (list): 255
We use the below configuration (/etc/lsyncd.conf):
settings{
pidfile = "/var/run/lsyncd.pid",
statusFile = "/var/tmp/lsyncd.status",
logfile = "/var/log/lsyncd/lsyncd.log",
statusInterval = 60,
logfacility = "user",
logident = "lsyncd",
inotifyMode = "CloseWrite",
maxProcesses = 10,
}
sync {
default.rsyncssh,
source = "/myfolder/",
delete = true,
host = "remote-host",
targetdir = "/myfolder/",
excludeFrom = "/etc/lsyncd/lsyncd.exclude",
delay = 5,
rsync = {
binary = "/usr/bin/rsync",
archive = true,
owner = true,
compress = true,
_extra = { "--bwlimit=50000", "--delete-after" },
rsh = "/usr/bin/ssh -l tomcat -i /usr/share/tomcat6/.ssh/id_rsa",
}
}
As a workaround we can use a /root/.ssh/config file with:
Host remote-host
Hostname remote-host
User tomcat
IdentityFile /usr/share/tomcat6/.ssh/id_rsa
Of course we would rather not have to use this since it should work with the lsyncd.conf configuration.
We're using lsyncd version 2.1.4
The following issue on GitHub helped to me solve the same problem:
https://github.com/axkibe/lsyncd/issues/369
What I did was quite simple, I just replaced default.rsyncssh with default.rsync in lysync.conf.lua file
When using rsyncssh, one has to be careful.
The "ssh {}" configuration parameter has its own "binary", "port", "_extra". See documentation for complete list of settings.
It is a little confusing because "rsync {}" also needs to be configured. Yes, both sections need to be done.
The "ssh" section is used for delete and move events. The "rsync" section is used for file transfer.
One might avoid the confusion by using rsync instead of rsyncssh. But, you would lose the bandwidth efficiency that rsyncssh provides when files get moved.
I have a basic LDAP setup without SSL configured. Users are able to login but not able to change their password using passwd command. I have gone though many blogs but no luck. I have disabled selinux and iptables.
Any help on this will be much appreciated.
Details below,
OS: CentOS6.5
LDAP version: openldap-servers-2.4.23-34.el6_5.1.x86_64
Client version: openldap-clients-2.4.23-34.el6_5.1.x86_64
Output from the terminal when trying to change the password:
[servername ~]$ passwd
Changing password for user dkrishna.
Enter login(LDAP) password:
New password:
Retype new password:
LDAP password information update failed: Insufficient access
passwd: Authentication token manipulation error
Below are the logs,
==> /var/log/secure <==
Oct 8 09:31:33 passwd: pam_unix(passwd:chauthtok): user "dkrishna" does not exist in /etc/passwd
Oct 8 09:31:42 passwd: pam_unix(passwd:chauthtok): user "dkrishna" does not exist in /etc/passwd
==> /var/log/messages <==
Oct 8 09:31:42 passwd: pam_ldap: ldap_modify_s Insufficient access
ACL's configured as below,
database config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.exact="cn=admin,dc=tibbr,dc=com" read
by * none
access to attrs=userPassword
by self write
by anonymous auth
by users none
access to * by * read
I found the solution:
Add the following two lines to the end of the file: oclDatabase\=\{2\}bdb.ldif
olcAccess: {0}to attrs=userPassword by self write by dn.base="cn=Manager,dc=domain,dc=com" write by anonymous auth by * none
olcAccess: {1}to * by dn.base="cn=Manager,dc=domain,dc=com" write by self write by * read
bye
Looks like slapd.conf is deprecated when OCL database is configured.
Observe the following snippet from OCL configuration guide:
"From the time you have run the conversion the slapd.conf file is redundant. When loading slapd looks for the configuration directory (default slapd.d) and reads its configuration files from there and initializes the OLC (cn=config) DIT. If the slapd.d directory is not found then slapd looks for slapd.conf."
The error:(occurring in the prod env)
request.CRITICAL: PDOException: SQLSTATE[28000] [1045] Access denied for user 'root'#'localhost' (using password: YES) (uncaught exception) at /srv/inta/current/vendor/doctrine-dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php line 36 [] []
What I've tried so far
The weird thing is that I actually have access using the root user, and the provided password. Logging in as root via the console works great.
I'm using the following parameters.yml file located in app/config/
parameters:
database_driver: pdo_mysql
database_host: localhost
database_port: ~
database_name: int_apartments
database_user: root
database_password: pw goes here
mailer_transport: smtp
mailer_host: localhost
mailer_user: ~
mailer_password: ~
locale: en
secret: ThisTokenIsNotSoSecretChangeIt
As you can see, it is quite standard with only the name of the db, user and password changed.
In my config.yml located in app/config (the relevant portions)
imports:
- { resource: security.yml }
- { resource: parameters.yml }
...
doctrine:
dbal:
driver: %database_driver%
host: %database_host%
port: %database_port%
dbname: %database_name%
user: %database_user%
password: %database_password%
charset: UTF8
dbname: int_apartments
orm:
auto_generate_proxy_classes: %kernel.debug%
auto_mapping: true
mappings:
StofDoctrineExtensionsBundle: false
Now, I wanted to start at "step 1" and verify that the parameters.yml file is actually being imported, so I changed the host to "localhos" or the user to "tom" or whatever and the error message located in app/logs/prod.log stays exact as is - the location doesn't change and the user doesn't change.
So I checked my config_prod.yml located in app/config
imports:
- { resource: config.yml }
#doctrine:
# metadata_cache_driver: apc
# result_cache_driver: apc
# query_cache_driver: apc
monolog:
handlers:
main:
type: fingers_crossed
action_level: error
handler: nested
nested:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: debug
...and everything seems standard!
Summary of what's going on
So here is the quick version.
Authentication error exists for root#localhost
Verified my authentication creditials by logging in as that user via the console
Want to check if the parameters.yml file is being loaded
Changed some values - none affected the error message
(small)Edit:
What I actually want to do is to connect to the DB as a completely different user with a different password. Even when I enter different credentials into my parameters.yml file, doctrine still spits out the "root#localhost" error.
Ideas?
Silly mistake, seems due to a bad user/group/owner configuration on the server.
the app/cache directory is owned by "root", but when I run
app/console cache:clear --env=prod --no-debug
I am running as another user (not root). So there were issues in clearing the cache and doctrine seems to have been using a very old configuration located in the cache files.
Lessons learned:
Always try running as root (as a last resort)
Use a properly configured web server to avoid ownership issues
I solved my problem by renaming the prod folder i uploaded to prod_old because the system could not delete the folder for some reason.
I'm currently trying to implement Devise with LDAP Authentication on RAILS3. I've got it setup and it appears to connect and try to auth, but appears to fail. I don't seem to get any sort of real error messages to work with so its very difficult to take it any further.
Log of login session:
Started POST "/users/sign_in" for 192.168.160.1 at Tue Dec 06 05:20:16 +0000 2011
Processing by Devise::SessionsController#create as HTML
Parameters: {"commit"=>"Sign in", "authenticity_token"=>"G2tEq9gPpJiN0RhanTd8HMWno62F+1oLWbU4xdX78bg=", "utf8"=>"\342\234\223", "user"=>{"remember_me"=>"0", "password"=>"[FILTERED]", "login"=>"richmond#email.com"}}
User Load (0.1ms) SELECT `users`.* FROM `users` WHERE `users`.`login` = 'richmond#email.com' LIMIT 1
LDAP: LDAP dn lookup: mail=richmond#email.com
LDAP: LDAP search for login: mail=richmond#email.com
LDAP: Authorizing user mail=richmond#email.com,ou=groupxx,o=company.com
LDAP: LDAP dn lookup: mail=richmond#email.com
LDAP: LDAP search for login: mail=richmond#email.com
Completed 401 Unauthorized in 7147ms
Processing by Devise::SessionsController#new as HTML
Parameters: {"commit"=>"Sign in", "authenticity_token"=>"G2tEq9gPpJiN0RhanTd8HMWno62F+1oLWbU4xdX78bg=", "utf8"=>"\342\234\223", "user"=>{"remember_me"=>"0", "password"=>"[FILTERED]", "login"=>"richmond#email.com"}}
Rendered devise/shared/_links.erb (0.1ms)
Rendered devise/sessions/new.html.erb within layouts/application (5.0ms)
Completed 200 OK in 23ms (Views: 21.4ms | ActiveRecord: 0.0ms)
Started GET "/assets/defaults.js" for 192.168.160.1 at Tue Dec 06 05:20:23 +0000 2011
Served asset /defaults.js - 404 Not Found (3ms)
ActionController::RoutingError (No route matches [GET] "/assets/defaults.js"):
Rendered /usr/local/lib/ruby/gems/1.8/gems/actionpack-3.1.0/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (0.5ms)
ldap config:
development:
host: ldap.company.com
port: 636
attribute: mail
base: ou=groupxx,o=company.com
#admin_user: cn=admin,dc=test,dc=com
#admin_password: admin_password
ssl: true
# <<: *AUTHORIZATIONS
I don't have access to the LDAP server so I cannot confirm anything from that end. The main issue I have is that I cannot get any error messages out of the login process - Is it not able to find the user? Does it find the user but fail login? Why does it do 2 LDAP searches?
same issue here. Did a ldapsearch, which works however. Company is running an ActiveDirectory server here:
ldapsearch -Z -h ldap.company.com -p 389 -s sub -D
"cn=somebody,ou=my_ou,dc=ldap,dc=company,dc=com" -W -b
"dc=ldap,dc=company,dc=com" "(&(cn=somebody))" mail
Solution:
I have found the solution: In config/initializers/devise.rb I missed to activate config.ldap_use_admin_to_bind = true. Only with this flag, devise_ldap_authenticatable really uses the BindDN (i.e. admin_user, admin_password which both have to be uncommented) defined at config/ldap.yml.
I found out the problem I had was that the LDAP server my company (IBM) uses was using a different protocol standard to the ones officially supported by NET-LDAP.
You simply need to change the PagedResults Control Type to a slightly different standard:
#PagedResults = "1.2.840.113556.1.4.319" # Microsoft evil from RFC 2696
PagedResults = "2.16.840.1.113730.3.4.2" # IBM Bluepages compatible ControlType
Full code change details here.
I forked it and fixed it over here on GitHub.
I did encounter the same problem on my ActiveDirectory. I tried using the bind user but it didn´t help either. I changed devise according to screencast 210 to use the username field. Here´s my ldap.yml
development:
host: dcburda0
port: 636
attribute: cn
base: OU=Organisation,DC=mydomain,DC=com
admin_user: CN=username,OU=Support Center Muenchen,OU=name GmbH,OU=Organisation,DC=mydomain,DC=com
admin_password: password
ssl: true