How to verify password on Unix (HPUX) - c

I'm writing a user daemon and when the user logs on, I want to make sure that the user is the one who started the daemon. Reason is, that I need some way of running commands which can take a lot of time. Using nohup for this has some drawbacks, like I can not interact with the process anymore, so the daemon should watch these processes and allow me to interact with them.
The problem now is, how can I verify the password, as the user will not have permission to read the shadowfile and the /etc/passwd passwort is not set.

You could use the PAM to check the user / passwd. It's also present in Unix systems. You should check the interfaces which are implemented in HPUX.
https://www.ibm.com/developerworks/linux/library/l-pam/

Im not sure on how to do daemons, but I do know that in C, all you would have to do is, create a string and check whether or not that is what the user types in.
have it accept what the user sets:
// accept
printf("1. login \n 2. create information ");
this gives them the option, then switch the options, case 1 being the information for logging in, and then case 2 being the option that allows them to type in the information, and you saving it in something to be read later, and determining if it already created or not.
Hope this helps!

Related

Hiding password field in command line

I am writing a system service on FreeBSD where I need to take user credentials to verify identity, something like this:
./compression_bin -i <input_file> --type=<type> --password=<secret key>
Here, the secret key is used to authenticate user before compressing the given file. Currently, the secret key shows up in history which is bad and can be exploited. Is there a way where above can be invoked without displaying password field:
./compression_bin -i <input_file> --type=<type> --password=*********
The history will always record the text of the commands as they were issued. You could conceivably go back and modify the history file, but not only is that nasty, it still affords a window within which the password can be read.
Moreover, that's not even the easiest exploit. If the password is given on the command line then there are other ways it can be read while the command is running, such as from the output of the ps command, which is accessible to all users.
So don't take the password as a command-line argument. Read it from a file or from the standard input or from a socket, or some other such thing.

Check if program is being piped

I'm writing a program that speeds up the git push operation. Here's what it needs to do:
printf("[github-username]\n[github-password]");
I'd then use it like so:
git-autologin | git push
But I don't want there to be any chance of someone simply typing git-autologin or git-autologin > file.txt and being able to see my username and password. I know it sounds silly 'cause anyone can still automate the git commands but it's unlikely that any untrusted user will ever get on my system.
My question: How could I tell if standard output is writing to a file/terminal or if it's being piped?
Edit: The git push pipe was simply an idea, not the only reason I'm asking.
Edit: Is there any way to determine the PID or more information about the process it's being piped to?
You can detect when stdout is a terminal by using (on Linux & POSIX!) the isatty(3) function, probably as isatty(STDOUT_FILENO)
So you could guess that if isatty(STDOUT_FILENO) is false, the standard output is would be redirected or piped.
Alternatively, use fstat(2) as fstat(STDOUT_FILENO, &stdoutstat);
But you should set up ssh correctly (with credentials, STFW for any SSH tutorial!) on your system, to avoid having git asking any password.

Unix: Prevent delete on a user file from a user

[UNIX] Assume that there exists a user X (i.e. not a superuser), which belongs to a group G. This user X creates a file F in a directory, with permissions "rw-rw----".
Is there a way to prevent delete on this file from any user (except superusers), with a command issued by user X?
I found "chattr +a", but it can only be issued by superuser.
In other words, I am user X, member of group G, I own a file which must have permissions "rw-rw----". I want to prevent this file from deletion by myself and any other user of group G.
A possible solution is to provide a script owned by root and with setuid flag on. That script would only run egainst files located in a particular directory so as to avoid a confused deputy attack.
An other possibility that I did not explore is to use ACL's which provide more granularity than the standard rwx.
Maybe you are trying to solve the wrong problem ("I want to protect against accidental deletion of my own files").
The usual countermeasure is backups and/or archival. For single files I simply check them in with RCS, i.e. ci -l precious.txt each time I modify them. Note that this solution also solves the problem of accidental modifications, since you can checkout any earlier version with ease.
See the manuals for rcsintro(1), ci(1), co(1) and rcsdiff(1).

autocomplete directory name with C

I have a C code, which prompts users for list of directory name, it just uses plain scanf() to receive the input and proceeds. Now I would like to provide autocomplete for directory names (like bash does). Say user enter /home/a and press TAB - it displays list of available user directories that begins with 'a'.how to achieve this?
scanf is not suitable for any kind of auto-complete or even interactive editing beyond the basic level (essentially just backspace) that the kernel cooked-mode terminal driver provides. If you want to do fancier interactive input, you need to change the terminal modes so you get each key event and process them yourself, or you can use a library like readline that does this for you.

How do I change linux user within C code?

How do I change the user that my c program identifies itself as?
A command-line tool I want to invoke automatically requires to be run as a specific user and won't work otherwise.
I have tried using setuid(0) but I still don't get the desired results.
The user I want to imitate is not 'root', but a normal unprivileged, shell-less user. I want to be able to run the binary logged in as the user nobody. I was able to concoct a solution as 'root' using:
su -ls /bin/bash -c /binary (superuser)
However I want to be able to achieve the same logged in as user nobody
Is there something I'm missing?
If anyone could just become root by putting setuid(0); in their program, Unix would be, well, Windows.
Some thoughts:
Running external command line tools from C is almost always a mistake.
If you really need this command line tool, does the tool really need root permission to work? If not, fix the tool (or go back to step 1 and incorporate the functionality into your own program).
If you really need the tool and it really needs root, consider setting up sudo permissions for it and running it via sudo.
Given the very basic question you're asking, you should not even attempt to write code that will run as root, so I've omitted any details about how to setup root permissions for your program.
You don't need to do anything on the C side. Just change the binary to be owned by the user you want to use, enable the setuid bit in the binary (chmod u+s), and you're all set!
(If you don't want any user to be able to run as your designated user willy-nilly, consider using sudo.)
To change the current userid:
Firstly, lookup the new userid using getpwnam(). This returns a struct passwd *pw and a NULL value will indicate that user doesn't exit. The struct contains the userid (pw_uid) and the group id (pw_gid) which are needed to perform the change.
if((pw = getpwnam(userid)) == NULL)
sprintf(error_msg "Userid '%s' does not exist", userid);
Then set the group id for the new user
if (setgid(pw->pw_gid) != 0)
sprintf(error_msg "setgid() to %d failed", pw->pw_gid);
Finally, set the user id for the new user
if (setuid(pw->pw_uid) != 0)
sprintf(error_msg "setuid() to %d failed", pw->pw_uid);
Error recovery during this process is messy. The easiest way is to simply abort if either setgid() or setuid() fails. The real problem occurs if changing the group succeeds, but changing the user fails.

Resources