I'm setting up samba on linux for single user access from Windows, and need to prevent password checking. I've added my linux username to smbpasswd. Despite the guest account setting in my smb.conf, files I create are owned by user nobody. How do I get samba to operate as my user id?
smb.conf:
[global]
security = share
guest account = liam
...
[goodstuff]
path = /home/liam
read only = no
guest only = yes
guest ok = yes
If this is a FAQ, apologies; I looked and looked for the answer.
This seems to be a common problem, for me it currently does NOT work if I have it in the share's section, but it works if it is in the global section. This is my share's definition:
[RepoDrive]
comment = USB drive
path = /shr
read only = No
create mask = 0777
directory mask = 0777
guest only = Yes
guest ok = Yes
browseable = No
According to the Samba manual, specifying guest account for the share SHOULD be okay and this is how it SHOULD be done... IMO, Samba has a LOT of issues. Note that if you want to find out as which user you are acting when you are a guest, make sure you have write permissions and create a folder, then you can check out the folder's owner, and this will be the user that samba used. For me, it is "nobody" (the default) if I specify the guest account in the share section.
Note that smbpasswd has nothing to do with these user definitions.
If all else fails, try to use testparm (you need sudo apt-get install samba-common-bin in order to get it). It will show you which parameters of your configuration are actually effective, and detect any irrelevant/incorrect parameters (it eliminates settings that you set to the default value, and rewrites synonyms, e.g. writeable = yes will become read only = no because these are antonyms).
The problem turns out to be
guest only = yes
With that removed, activity happens as the guest account user id.
The solution for me was to add "guest account = accountname" to the share in stead of the [global] part.
Related
I've set up a private wiki for a class, and I'd like the students to create their own accounts (saving me from having to manually create them and email them instructions on how to login).
In LocalSettings.php, I changed the settings to the following:
# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['createaccount'] = true;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
My intention is for anyone to create an account (I can add the ConfirmAccount extension if need be, but more likely I'll just change the flag to false after my students have signed up), but nobody can read or edit pages without becoming a user.
On the main page of the wiki, there is now a link to Create Account. However, clicking it just leads back to the Login prompt. The only way I can get the Create Account page is by changing all of the permissions above to true.
Is there a way to block read/edit access but allow account creation?
Okay I found a solution--surprising this wasn't included in the mediawiki documentation on the pages for managing users or restricting access.
Add this line to LocalSettings.php:
$wgWhitelistRead = array( 'Special:RequestAccount', 'Main Page', 'Special:CreateAccount' );
Intro
Our apache2 setup serves files from a wide variety of folders using webdav, and use authz_dbd to communicate with a mysql database (this part works without problems).
Summary:
Apache2, mod_authz_dbd, mod_authn_dbd, mysql, enabling webdav, multi user environment (iot nodes).
However... some of these folders are user specific.
folder1 admins
+--subfolder1.1 admins+some other folk+user1
+--subfolder1.2 admins+again other folk+user1
folder2
+--subfolder 2.1 same as 1.1 but with user2
+--subfolder 2.2 as1.2.. but..user2
We use dbd-groups with wildcards, similar to this:
location /var/www/html/*/subfolder1.1
require dbd-group read
And normally wrote all in the vhosts file
(require user.. )
The problem
This becomes too large, we need another fix.
We cannot use .htaccess files in combination with dbd groups (dbd groups are not allowed in .htacces). Our debian (jessy) does not allow the other mysql apache2 mods.
The combination of .htaccess files with dbd's mysql authorization does not work (dbd groups are not allowed in .htaccess).
Our debian server does not allow other mysql apache2 mods (like mod_auth_mysql).
How can I combine mysql authorization with the folder specific users?
Ok, i believe ive cracked it:
Technique
Apache natively support for named groupes and backreferances.
The capture group can be employed to identify the folder (and with this the user).
How does this work;
every subdir with of the hosted directory (/var/www/web)
Beginning with M and containing at least three decimals (M\d{3,}) <- the capture group.
This is stored in a variable ( sitedir)
eg.
/var/www/web/M1234/etc. sitedir=M1234
/var/www/web/M1234567/test/ANY other directory sitedir=M1234567
In my case I match the user with the directory name require user %{env:MATCH_SITEDIR}
Be very aware to use the queries outside the require directives (as shown below).
Using cascaded RequireAny/Requireall other requirements can be made
(requirements on dbd groups, ip ristrictions etc).
Drawbacks
The capture group might allow for multiple folders with an Mcode.
This can be mitigated by adapting the capture group.
The captured foldername cannot be used inside the query (it does not allow this)
This would have been even nicer, but it does not work...(the variable is considered plain text).
working example
<DirectoryMatch /var/www/web/(?<sitedir>(M\d{3,}))>
AuthDBDUserPWQuery "SELECT password FROM mysql_auth WHERE username = %s"
AuthzDBDQuery "SELECT groups FROM mysql_auth WHERE username = %s"
<RequireAny>
Require user %{env:MATCH_SITEDIR}
<RequireAll>
Require valid-user
Require ip 10.0.0.0/16
<RequireAny>
Require dbd-group internal
Require dbd-group write
</RequireAny>
</RequireAll>
</RequireAny>
</DirectoryMatch>
I am trying to debug a weird issue with one user's roster in ejabberd.
He is having a roster group "_root" show up in his client (PSI).
The server is using mod_ldap for user authentication.
Things tried so far:
deleting the group from the client -> the group appears again after a while
unregistering the user with /ejabberdctl unregister user domain.com -> the group appears again after a while
Only one user is affected by this on the server, which makes me think it has to be something specific to this one user's settings (or client). But we have a bunch of people also using PSI with no problems.
Is there a way to look at the roster groups defined for a specific user in the database directly?
Thanks,
kaza
That "_root" value must come from the roster module data. You did not say which roster module you use, but I guess the server is configured to use mod_roster_ldap and possibly mod_shared_roster_ldap. Check the configuration of the module and explore the content of the LDAP directory to see if you see that value. I would think that value comes from there.
I've lost the admin user password on hudson (actually it just randomly stopped working), I can get back in by disabling security (editing ~/.hudson/config.xml) then I can configure hudson, but I can't find any options to add new users or change/reset user passwords - maybe these options don't appear when security is disabled? I was using the matrix-based security. How can I add a new user or reset the password for existing ones?
Here is an article outlining how that is achieved.
The first one: edit the authorization setting in the config.xml file
if you have defined more users in your Hudson and you at least one
user’s password. For example, your user name called peter and you know
the password of the user jack, in this case, just open the
%HUDSON_HOME%/config.xml and find the line:
<permission>Hudson.model.Hudson.Administer:peter</permission>
And add a new line below:
<permission>Hudson.model.Hudson.Administer:jack</permission>
Save your change and restart your Hudson server, then you can login as
jack and change your own password. After then login using your own
account and go to http://your/hudson/configure and change jack back
to his normal authorization setting.
The other way ist just editing your own config.xml, in this case, open
%HUDSON_HOME%/your/config.xml and find the line:
<password>………</password>
The text between the password tag is encoded, so you can’t just enter
your password as plain text here. The easy way for you now is just
remove all the text between that tag, in another word, just let the
password empty.
Hope this helps.
In Hudson 3.0, security is defined in a separate file, hudson-security.xml. Same directory though.
Just edit the <useSecurity>true</useSecurity> entry and specify false.
If you have access to the jenkins files, edit the config.xml.
/var/lib/jenkins/config.xml
Change
<useSecurity>true</useSecurity>
<useSecurity>false</useSecurity>
And comment to
<authorizationStrategy/>
Ref:
http://it.i88.ca/2013/04/reset-password-of-jenkins.html
Greetings!
I use Jenkins, but this should be similar in Hudson. You need to be logged in as a user with administrative permissions, so configuring Hudson to use security is essential. Look for a 'Manage Users' link in the 'Manage Hudson' page (the main configuration page linked from the main page). The 'Manage Users' page should give you a list of users that have been configured for use with Hudson and you should be able to add/edit/delete users from here.
Read this article for more information on configuring security in Hudson.
mercurial-server manages user database under keys folder. Users and groups are represented by files and folders.
AclExtension relies on linux user group through ssh.
they don't seem to match. or did I miss something?
I have managed to make mercurial-server work. but just don't see how to integrate AclExtension with it so I may have finer grained access control.
Unfortunately, the AclExtension does key its access off of usernames. If you are creating separate UNIX user accounts for each using with hg-ssh you've got everything you need, but if all of your ssh users are using the same Unix user account then the AclExtension isn't going to work for you.
Unless...
I did just look into the acl.py file and it looks like it uses the getpass.py module's getuser which checks the environment for the user name using this code:
for name in ('LOGNAME', 'USER', 'LNAME', 'USERNAME'):
user = os.environ.get(name)
if user:
return user
so it might be possible to fake that out by setting an environment variable in the hg-ssh user's authorized_keys file like this:
command="hg-ssh path/to/repo" environment="LOGNAME=fakeusername" ssh-dss ...
where then you could put fakeusername in ACL rules, and could have a different fakeusername for each key, all running under the same UNIX account.
BTW: Everyone seems to just use hg-ssh alone, I never see the (non-official) mercurial-server app used anymore.
The environment trick doesn't seem to work on my Solaris box; my solution was to pass in the fakeusername as a parameter to hg-ssh and have that set os.environ['LOGNAME'] so that getpass sees it.
command="hg-ssh fakeusername" ssh-dss ...