I'm adding a package in buildroot. Notably fcron-3.2.1. The documentation says to put this in the package makefile (fcron.mk) :
LIBFOO_USERS
Lists the users to create for this package, if it
installs a program you want to run as a specific user (e.g. as a
daemon, or as a cron-job). The syntax is similar in spirit to the
makedevs one, and is described in the Chapter 24, Makeusers syntax
documentation. This variable is optional.
So my fcron.mk file looks like this :
#############################################################
#
# fcron
#
#############################################################
FCRON_VERSION = 3.2.1
FCRON_OVERRIDE_SRCDIR = ../fcron-3.2.1
FCRON_OVERRIDE_RSYNC = YES
FCRON_INSTALL_STAGING = YES
FCRON_INSTALL_TARGET = YES
FCRON_SITE_METHOD = local
FCRON_CONF_OPTS = --enable-shared
FCRON_SITE = www.nomad-digital.com
define FCRON_USERS
fcron -1 fcron -1 * - - - Fcron daemon
endef
$(eval $(autotools-package))
When I try to install in buildroot, I get the following error.
>>> fcron custom Installing to staging directory
Checking if group fcron exists ... no.
Would you like to add fcron in /etc/passwd with the following command ?
groupadd fcron
If you use NYS, ldap, etc, you should add the group manually (say no here)
Please answer with 'y' or 'n' (default: 'y'): y
groupadd: Permission denied
groupadd cannot lock /etc/group; try again later.
Group "fcron" does not exists : please create it or choose another groupname with configure script.
I have a feeling that I'm trying to create a user on the host machine not in my buildroot image, but even when I answer with 'n' above, it still does not pass and just says to please create a user. AM I createing the required user and group correctly in buildroot?
It is the fcron build system that tries to add the user and group to the host, since it apparently doesn't consider installation in a staging directory. You need to tell the fcron build system NOT to add the user and group during installation. If this is not immediately obvious from the fcron configuration options, you can look how distributions solve it, they will have the same problem. Possibly you will need to patch its Makefile.am and set FCRON_AUTORECONF = YES in fcron.mk.
Related
We could map standard linux user into SElinux user accounts. Consider I am having a standard linux user with name "Steve".
Now, I am having 2 questions.
a.) If I map "Steve" into user_u (SElinux account), then he will get execution permission on $HOME & /tmp directory. Can I restrict "Steve" from executing applications in $HOME or /tmp. I tried using "neverallow" statement in policy file (*.te), and ended in following error message.
Error Message:
"libsepol.check_assertion_helper: neverallow violated by allow user_t bin_t:file { read getattr open };"
How could I override default permissions like user_u is having execution permission in $HOME in SELinux??
b.) I have created a file and changed it's type to "mytype_t" using chcon command. Then added "allow user_t mytype_t: file { read write execute };" into my policy. I have added mytype_t to /etc/selinux/default/contexts/files/file_contexts & /etc/selinux/default/modules/active/file_context. "seinfo -t" doesn't list mytype_t.
I could successfully create *.pp file. When I tried to install this policy using "semodule -i myPolicy.pp", I have ended with the following error message. It seems, mytype_t is not recognized by SElinux Policy.
Error Message:
libsepol.print_missing_requirements: user_execution_permission's global requirements were not met: type/attribute mytype_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule: Failed!
Simply I just want to create user "Steve" who can execute aare having standard linux users that are mapped into SElinux user-account. For example "Steve" is a standard linux user-account that can be mapped to any of the following, such as user_u (or) staff_u (or) system_u (or) unconfined_u.ll files with type "mytype_t" in anywhere in system, But should not be able to execute applications with other types.
I am working on debian 6 with policy.24, Thanks in advance for help!
In our product, we had created services using daemontools. One of my service looks like this,
/service/test/run
/service/test/log/run (has multilog command to log into ./main dir)
/service/test/log/main/..
All the process and its directories are owned by root user. Now there is a security requirement to change like this,
Service should run in non-root user.
Log main directory should be readable only to user and groups.
For this, I have to change the 'run' file under 'log' directory. Also I need to change the permissions of 'main' directory under it.
Note that all these files under '/service' were owned by test-1.0-0.rpm. When I update my rpm, it overrides the existing run file and got error like this,
multilog: fatal: unable to lock directory ./main: access denied
I know we shouldn't override the 'run' file at run time. I have planned to follow these steps in my rpm script %post section,
//Stop service
svc -d /service/test/log
//Moving the main directory
mv /service/test/log/main /service/test/log/main_old
//Updated run file has code to create main with limited permissions.
//Start service
svc -u /service/test/log
In some articles, they suggested to recreate the 'lock' file under 'log/main'. Is there any other cleaner way of doing this without moving 'main' directory ? If not, is it safe to go with the above steps ?
Ok, so I'm trying to configure and install svnserve on my Ubuntu server. So far so good, up to the point where I try to configure sasl (to prevent plain-text passwords).
So; I installed svnserve and made it run as a daemon (also installed it as a startup script with the command svnserve -d -r /var/svn).
My repository is in /var/svn and has following configuration (to be found in /var/svn/myrepo/conf/svnserve.conf) (I left comments out):
[general]
anon-access = none
auth-access = write
realm = my_repo
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256
Over to sasl, I created a svn.conf file in /usr/lib/sasl2/:
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/my_sasldb
mech_list: DIGEST-MD5
I created it in that folder as the article at this link suggested: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl (and also because it existed and was listed as a result when I executed locate sasl).
Right after that I executed this command:
saslpasswd2 -c -f /etc/my_sasldb -u my_repo USERNAME
Which also asked me for a password twice, which I supplied. All going great.
When issuing the following command:
sasldblistusers2 -f /etc/my_sasldb
I get the - correct, as far as I can see - result:
USERNAME#my_repo: userPassword
Restarted svnserve, also restarted the whole server, and tried to connect.
This was the result from my TortoiseSVN client:
Authentication error from server: SASL(-13): user not found: unable to canonify
user and get auxprops
I have no clue at all in what I'm doing wrong. I've been scouring the web for the past few hours, but haven't found anything but that I might need to move the svn.conf file to another location - for example, the install location of subversion itself. which svn results in /usr/bin/svn, thus I moved the svn.conf to /usr/bin (although that doesn't feel right to me).
Still doesn't work, even after a new reboot.
I'm running out of ideas. Anyone else?
EDIT
I tried changing this (according to what some other forums on the internet told me to do): in the file /etc/default/saslauthd, I changed
START=no
MECHANISMS="pam"
to
START=yes
MECHANISMS="sasldb"
(Actually I had already changed START=no to START=yes before, but I forgot to mention it). But still no luck (I did reboot the whole server).
It looks like svnserve uses default values for SASL...
Check /etc/sasl2/svn.conf to be readable by the svnserver process owner.
If /etc/sasl2/svn.conf is owned by user root, group root and --rw------, svnserve uses the default values.
You will not be warned by any log file entry..
see section 4 of https://svn.apache.org/repos/asf/subversion/trunk/notes/sasl.txt:
This file must be named svn.conf, and must be readable by the svnserve process.
(it took me more than 3 days to understand both svnserve-sasl-ldap and this pitfall at the same time..)
I recommend to install the package cyrus-sasl2-doc and to read the section Cyrus SASL for System Administrators carefully.
I expect this is caused by the SASL API for the call
result = sasl_server_new(SVN_RA_SVN_SASL_NAME,
hostname, b->realm,
localaddrport, remoteaddrport,
NULL, SASL_SUCCESS_DATA,
&sasl_ctx);
if (result != SASL_OK)
{
svn_error_t *err = svn_error_create(SVN_ERR_RA_NOT_AUTHORIZED, NULL,
sasl_errstring(result, NULL, NULL));
SVN_ERR(write_failure(conn, pool, &err));
return svn_ra_svn__flush(conn, pool);
}
as you may see, handling the access failure by svnserve is not foreseen, only Ok or error is expected...
I looked in /var/log/messages and found
localhost svnserve: unable to open Berkeley db /etc/sasldb2: No such file or directory
When I created the sasldb to the above file and got the permissions right, it worked. Looks like it ignores or does not use the sasl database path.
There was another suggestion that rebooting solved the problem but that option was not available to me.
I am trying to create a custom provider for package but for some reasons I keep on getting
err: Could not run Puppet configuration client: Parameter provider
failed: Invalid package provider 'piprs' at
/usr/local/src/ops/services/puppet/modules/test/manifests/init.pp:5
I have added pluginsync=true in puppet.conf in both client and server. I have created the following rb file in module/test/lib/puppet/provider/package/piprs.rb. I am basically trying to create a custom provider for package resource type
#require 'puppet/provider/package'
Puppet::Type.type(:package).provide(:piprs,
:parent => ::Puppet::Provider::Package) do
commands : pip => "/usr/local/bin/pip"
desc "Python packages via `pip`."
def create
pip "freeze"
end
def destroy
end
def exists?
end
end
In the puppet.conf, there is the following source attribute
pluginsource = puppet://puppet/plugins
I am not sure what it is. If you need anymore details, please do post a comment.
First things first - you do realize there is already a Python pip provider in core?
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/pip.rb
If that isn't what you want - then lets move on ...
For starters - try your module without a Puppet master - this is going to be better for development anyway. You need to make sure Ruby can find the library path:
export RUBYLIB=<path_to_module>/lib
Then, try writing a small test in a .pp file:
package { "mypackage": provider => "piprs" }
And run it locally:
puppet apply mytest.pp
This will rule out a code bug in your provider versus a plugin sync issue.
I notice there is a space between the colon and the command - that isn't your problem is it?
commands : pip => "/usr/local/bin/pip"
If you can get this working without a puppetmaster, your problem is sync related.
There are a couple of things that can go wrong - make sure the file is sync'd properly on the client:
ls /var/lib/puppet/lib/puppet/provider/package
You should see the piprs.rb file there. If it is, you may need to make sure your libdir is set correctly:
puppet --configprint libdir
This should point to /var/lib/puppet/lib in most cases.
Is there a way to prevent users from doing 'cvs init'?
'cvs init' creates a new repository. The doc says it is a safe operation on an existing repository, since it does not overwrite any files. But the problem is, administrative files in CVSROOT will be changed.
For example, we have a CVSROOT/loginfo script that mails commit info to a mailing group. After doing cvs init on that repo, it is replaced by a 'clean' version.
We use cvs 1.12.13 on a linux box running as stand-alone server and connect mostly from windows using the pserver protocol.
Setting the rights in CVSROOT didn't help, because the cvsd daemon runs as root. (It needs to incorporate into the executing user).
Problem is, that some users not so familiar with cvs tried 'cvs init' instead of 'cvs import' to create a new module.
I'm assuming that you have sysadmin authority over the machines. You could provide a wrapper around the real CVS binary to prevent certain commands from running and store this wrapper in such a way that it gets picked up before the real CVS. It's a bit of a hack but in a pinch, it would work:
#!/bin/bash
REAL_CVS=/usr/bin/cvs
case $1 in
init)
echo "The use of $1 is restricted. Contact your CVS administrator"
exit 1
esac
$REAL_CVS $*`
An other option would be to recompile the CVS client to disable the init command. Take a look at:
http://cvs.savannah.gnu.org/viewvc/cvs/ccvs/src/client.c?revision=1.483&view=markup
It would be trivial to modify this function to print out something.
void
send_init_command (void)
{
/* This is here because we need the current_parsed_root->directory variable. */
send_to_server ("init ", 0);
send_to_server (current_parsed_root->directory, 0);
send_to_server ("\012", 0);
}