$HOME, /etc/passd, and application behavior

Xyne · 2012-03-04 23:43:10

It's possible to present a different home directory to an application by launching it with

HOME=/foo/bar someapp

That works in most cases, but it's still possible for an application to parse /etc/passwd directly and get the default home directory. Is there any way to prevent that, i.e. to hide the home directory in passwd from a given application?

thisoldman · 2012-03-05 02:18:06

I just spent an hour researching this. So far, all I've come up with is a workaround.

You could create a user without a home directory, that is, useradd without using the -m option. With the defaults in '/etc/login.defs', a home directory is listed in '/etc/passwd' but the directory doesn't exist. The homeless person would still need a password for you to su to that user. Create a hidden home(?), change permissions, and so forth...

I haven't explored setgid and acl to see if they would make this easier, but I did catch your other post.

knopwob · 2012-03-05 02:38:49

Maybe something like this https://bbs.archlinux.org/viewtopic.php?id=96790 to override the 'open' call with your own, that checks if the file is /etc/passwd and opens /etc/passwd.fake instead.

Xyne · 2012-03-05 04:10:50

Thanks for the replies.

@thisoldman
If I use other user accounts then I can just set the home directory to whatever I need, which is actually my current solution. It works, but it forces me to deal with file permission issues as you noticed in the other thread.

@knopwob
LD_PRELOAD only works with dynamically linked applications (correct me if I'm wrong). I'm hoping that there's some way to guarantee that all applications see the home directory that I want them to see.

Blµb · 2012-03-05 09:25:50

This might be somewhat... more than what you actually want/need, but you could use namespaces for this, but you'd have to maintain a second /etc containing whatever your applications need to be able to access.
Basically you can bind-mount a different etc to /etc inside a new namespace (not affecting the rest of the system, essentially overwriting /etc for the current process)

With the code below - simply compiled without any special compile options, you can do this:
Create /private_etc with only a copy of passwd files with a changed home directory (and mtab pointing to /proc/mounts) (you could bind-mount (or rbind) the original /etc to another place first and have your private etc symlink all the other files you need)
as root (unless your user has mount capabilities) do:

newns
mount -n --bind /private_etc /etc
su your_user

newns: uses the CLONE_NEWNS syscall

// _GNU_SOURCE to have CLONE_NEWNS defined
#define _GNU_SOURCE
#include <sched.h>
#include <syscall.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
	syscall(SYS_unshare, CLONE_NEWNS);
	// simply execute the provided shell
	if (argc > 1)
		return execvp(argv[1], &argv[1]);
	// or just...
	return execv("/bin/sh", NULL);
}

Links:
http://www.debian-administration.org/articles/628
http://www.ibm.com/developerworks/linux … index.html (this might be interesting, a PAM code snipped to get per-user /tmp)
http://glandium.org/blog/?p=217

Last edited by Blµb (2012-03-05 09:26:18)

Xyne · 2012-03-05 17:44:24

Thanks Blµb, that looks promising.

Arch Linux

#1 2012-03-04 23:43:10

$HOME, /etc/passd, and application behavior

#2 2012-03-05 02:18:06

Re: $HOME, /etc/passd, and application behavior

#3 2012-03-05 02:38:49

Re: $HOME, /etc/passd, and application behavior

#4 2012-03-05 04:10:50

Re: $HOME, /etc/passd, and application behavior

#5 2012-03-05 09:25:50

Re: $HOME, /etc/passd, and application behavior

#6 2012-03-05 17:44:24

Re: $HOME, /etc/passd, and application behavior

Board footer