I have a system user on all of my systems that gets a default password; we're using a vendor for this, and we aren't able to remove the password from the initial setup.
We're currently setting the shell to nologin; is there any way with the User module to remove the password?
I could use the shell module to replace the password with !! in the shadow file, but I feel like Ansible probably has a better solution, and I just haven't found it yet.
The last time I looked into this, there was no "good" solution. I do something like this when I need to:
- name: Lock root password
user: name=root password='!'
Related
I tried enforcing difok=7 for root but can't get it to work. By now I tried every combination and it's just not working. I can't find any information in the manpage about this problem.
Is this normal that pam_cracklib is not enforcing difok=7 for root?
This is the configuration I am using: password requisite pam_pwquality.so retry=3 difok=7 minlen=10 ucredit=-1 dcredit=-1 maxrepeat=3 reject_username enforce_for_root
Possible duplicate of https://unix.stackexchange.com/questions/239002/why-roots-password-change-doesnt-require-old-password.
In short: When you change the password for root it does not check for the old password, because this check would be pointless as it adds no additional security.
I'm looking for a way to make ansible read a file from a certain location regardless of user (i.e. I would like to make the scripts usable for any user).
Unfortunately, ansible seems to like hard-coded paths: /home/user/foo/bar.yml works; ~/foo/bar.yml does not work.
I've tried to use these variants (none of which seem to work):
- import_playbook: ~/Documents/foo/bar.yml
- import_playbook: "{{ lookup('env','USER') }}/Documents/foo/bar.yml"
- import_playbook: "/home/{{ lookup('env','USER') }}/Documents/foo/bar.yml"
How can I achieve making ansible read the from a given directory regardless of user? I'd like these scripts to be executable for anyone.
Thanks.
EDIT: Ideally, I'd like to make the script executed by the current user, too: e.g. become_user: current (don't know if the latter command is possible to use).
Assuming node is running as root, how do I:
Add a new local (OS) user account and get its uid?
Delete an account by name?
The accounts will be used for daemon processes, so they needn't be full-fledged user accounts.
Doing this on Linux is priority one, doing it on OS X would be nice, and super bonus for supporting Windows.
On Linux, I suppose you could just spawn useradd, but how would you determine the new user's uid? Would it be better (or worse) to modify /etc/passwd and friends directly?
On Windows, it looks like NetUserAdd is the right place to look; has someone already written an addon to call it?
For Linux, once you've created the account with useradd, you could call getent passwd <username> to see all the main relevant account details, including, in the 3rd field, the uid.
Example:
# useradd -c "Jamie Carter" jamiec
# getent passwd jamiec
yields:
jamiec:x:2722:500:Jamie Carter:/home/jamiec:/bin/false
To grab the uid in a one liner, you could combine the cut command to grab the 3rd field while treating : as the delimiter:
$ getent passwd jamiec | cut -d: -f 3
2722
Generally it's much safer and easier not to manipulate /etc/passwd and friends directly. Most of what you would need to do is likely already in a system command somewhere. For example, userdel <username> will delete an account by name from /etc/passwd, but also takes care of removing the user from /etc/groups so you don't have orphaned information left there. (You would have to deal with this yourself if you wrote your own user-deleter.)
This is a big & broad question (MacOS, Windows, Linux all together), but to create a new user from the command line on the Macintosh is not trivial and would require you to be authenticated as root / admin.
It's possible to get root privileges by simple code like this:
char *name[2];
name[0] = "/bin/bash";
name[1] = "-p";
name[2] = 0x0;
execve(name[0], name, 0x0);
but this solution requires to set sticky bit chown root:root; chmod u+s.
The question is how to get root privileges only by providing user name and password (by process and to this process, - so process asking user for login information and use this permission to execution).
Issue is solved by providing a root passphrase directly to su utility. It can be easily riched by using fd_set or pipes and system call forkpty that returns a ready to login shell.
Please check my post that describe this question and shows a solution:
http://www.andreypudov.com/2013/02/user-authorization-in-linux.html
I've created a new whoami command which requires a fake username and have put it in the PATH by adding it to ~/.profile . It is created in a way that whoami is called before actual the actual whoami from Linux.
The main reason to do this is because I am remote accessing a Hadoop cluster and want the copied files to be under the fake username.
This works fine when I call whoami in the shell and even calling $PATH shows the path to my created whoami before everything else. But for some reason, when Hadoop is called, it doesn't pick the created `whoami'.
Can someone help me with how to fix this?
thanks
Most applications do not use whoami to determine a user's username or group. For instance, in bash you can use the command id to find more detailed information about yourself or id [username] (such as id root) to find out more detailed information about other users. Groups can be found with groups as well. Also, different programming languages, such as C, have their own methods of determining user identities such as the getuid() command.
If you really "need" to go as far as faking your user account, you'll need to go down to OS level and create hooks into the kernel/API that handles those methods.
Is it possible that you simply chown the files after they are copied instead?
UPDATE:
It appears that some releases of Hadoop do actually use whoami (my own implementation w/ clustering does not).
In this event, the best (a term loosely used) suggestion would be to move the legitimate whoami executable and create a whoami shell script that goes in it's place. The custom script should validate the current user and if it's "hadoop", return whatever faked username you want - otherwise return valid output. Igor's answer would work in this case.
I suppose that hadoop uses other PATH variable then you have in your shell.
You can tune its PATH and add the directory with fake whoami to its beginning.
When it is impossible,
you can write a small wrapper for whoami (I'm not sure that it is a good idea but you can do this if you want) that will run original whoami except when the script is executed by hadoop:
#!/bin/sh
WHOAMI=/bin/whoami.orig
if [ "$($WHOAMI)" = hadoop ]
then
echo fake
else
exec $WHOAMI "$#"
fi