FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Embedded

 
 
LinkBack Thread Tools
 
Old 02-22-2010, 02:19 PM
Peter Stuge
 
Default emerge --root : users not created

P. Levine wrote:
> It seems absurd to add support for chroot() in useradd and groupadd
> without userdel and groupdel, so the patch includes support for them.

gpasswd has also been mentioned. Please check what
portage/eclass/eutils.eclass actually uses, or ideally add the flag
to all the shadow utilities?


> xfgetXXbyYY

Why is all that required? It's a mess. Please explain?


//Peter
 
Old 02-22-2010, 05:44 PM
"P. Levine"
 
Default emerge --root : users not created

On 02/22/2010 10:19 AM, Peter Stuge wrote:
> P. Levine wrote:
>> It seems absurd to add support for chroot() in useradd and groupadd
>> without userdel and groupdel, so the patch includes support for them.
>
> gpasswd has also been mentioned. Please check what
> portage/eclass/eutils.eclass actually uses, or ideally add the flag
> to all the shadow utilities?

I did check the eclasses. Eutils calls useradd and groupadd. The only
other mention of a shadow utility is games.eclass with:

ewarn "Just run 'gpasswd -a <USER> ${GAMES_GROUP}', then have <USER>
re-login."

I would consider patching all of shadow utilities to be ideal. But I'm
not sure whether the shadow devs would. I was under the impression this
was for useradd and groupadd (and, consequently, userdel and groupdel).
I'll try to get a hold of them on IRC when I get a chance.

>
>> xfgetXXbyYY
>
> Why is all that required? It's a mess. Please explain?
>
>
> //Peter
>
>

From my previous post:

> There are a number of calls to "getXXbyYY" functions (i.e., getgrgid,
> getpwnam, etc...). These seem to be dynamically preloaded and access
> preloaded databases. They are unaffected by chroot() (even after
> setting __nss_configure_lookup(foo, files)). I've instead used shadow's
> own method of macro expansion to generate functions doing the
> equivalent, with recursive calls to fgetXXent functions.

There are numerous calls to libc functions such as getgrgid and getpwnam
by shadow's own xgetgrgid and xgetpwnam. These are generated by files
containing macros, and at the bottom there's #include xgetXXbyYY.c, a
file the does the macro expansion. In the end, they generate wrapper
functions to initialize buffers, call the function, and duplicate and
return the struct. xgetgrgid, for instance, calls getgrgid to search
the group database for a particular gid, and returns a pointer to the
group struct if it exists. The problem is the databases are dynamically
preloaded and chroot() will not. The only mention in the glibc manual
about forcing related functions to use a particular database method is
by calling __nss_configure_lookup. Even if this did work with chroot()
it would be initializing databases from $ROOT/etc as the system
databases for the duration, which would be absurdly dangerous in a
system where other utils and libs could call on the same databases.

Glibc offers fgetXXent functions (fgetpwent, for example) which, simply,
sequentially return the next struct from a file stream supplied as the
argument. There are no fgetgrgid or fgetpwnam functions. My original
patch supplied those functions using its own xfgetXXbyYY.c and
associated macro files by recursively calling fgetXXent functions and
comparing the struct member to the argument. But after looking at
userdel.c and groupdel.c, I saw that they made calls to setXXent,
getXXent, and endXXent functions (which use the system database) that
would have changed too many lines of their code if patched. So I added
fsetXXent, fgetXXent, and fendXXent functions, and changed all the
others to, very simply, call on those.

The chroot.c file might seem like a mess but it's actually quite
organized, and if you cd to the patched source directory, configure, run
"gcc -E -I ./lib -I . -o chroot.expaded.c ./libmisc/chroot.c", and
scroll to the bottom of chroot.expaded.c, you'll see what functions
those macros expand to.
 
Old 02-23-2010, 03:58 PM
Ned Ludd
 
Default emerge --root : users not created

On Mon, 2010-02-22 at 09:41 -0500, P. Levine wrote:
> Attached is the final version of the chroot patch. I'll submit it in
> the next few days.
>
> It seems absurd to add support for chroot() in useradd and groupadd
> without userdel and groupdel, so the patch includes support for them.
> Also, to create a smaller footprint, I've combined all applicable
> functions into one file. The downside is more complex macro expansions
> (comments included, though), but it allows for a more integrated
> interface (generated function xfgetXXbyYY calls generated functions
> xfsetXXent, xfgetXXent, and xfendXXent), and less alteration of shadow's
> own code.
> PAM isn't a concern because chroot() only strictly works in a process
> with an su uid. And a function to parse the chroot flag before any
> others (leaving argv and argc in a pristine state) is included.
>
> -- Peter Levine

This seems a major improvement over the previous from quickly glancing
over the code. In no time at all I'm sure you will be ready to re hit
upstream.

Q:
If the end user is using Linux-Pam on his/her host system and they run
this. It will ignore loading extra pam modules when entering the chroot?
Or do they flat out need to disable pam on the host so they can take
advantage of this for the chroot?
 
Old 02-24-2010, 01:01 AM
"P. Levine"
 
Default emerge --root : users not created

On 02/23/2010 11:58 AM, Ned Ludd wrote:
> Q:
> If the end user is using Linux-Pam on his/her host system and they run
> this. It will ignore loading extra pam modules when entering the chroot?
> Or do they flat out need to disable pam on the host so they can take
> advantage of this for the chroot?

They don't need to disable pam for useradd, groupadd, etc... for the
same reason they don't for the chroot command. PAM is for
authenticating users (attempting to ensure that a user who wants to use
a utility that he or she already has permission to, is indeed that
user). Also keep in mind that all the chroot() function does is
(basically) prefix the path string in any functions (within the same
process or child processes) explicitly dealing with paths (fopen, for
example) with a sub path string (as if the process is changing the
directory to the chroot() path and then treating all absolute paths from
that point on as relative paths, and paths prefixed with "./" are
treated relative to the ACTUAL directory the process exists in , i.e.
the program was called from).

The chroot() function is privileged process with the CAP_SYS_CHROOT
capability. Even the chroot program which uses the chroot() function
doesn't check if you're root, if it should delegate such a capability on
a particular uid or call on PAM. It assumes it is being run as root and
if chroot() fails it simply spits out "cannot change root directory to
...". My patch at least checks if the uid is 0 and if not emits "must
be superuser for chroot access".

PAM processes are called by shadow (at least where I've encountered them
so far) to pre-authenticate a user (and only when both
--enable-account-tools-setuid and --with-libpam were enabled at
configure time) to use the particular utility. That it would do so even
if the user was root seems to me a redundancy (since a system
would/should not allow root to grant or deny certain access rights
to/from itself). When the program is called (suid bit enabled) PAM
takes care of the uid, euid discrepancy. The chroot() process however,
shouldn't be called by a non-root user, period. There are non-standard
modules on other systems to enable suid + chroot() + PAM authentication,
they are used to mimic the chroot utility (so a user can login to their
own subdirectory jail). It seems to me it would be an unnecessary
security risk to allow a non-root user to authenticate to add/delete
users/groups from an offset directory. This should be left to root
only. Otherwise a dependency on pam_chroot or some other non-standard
module would have to be created, or a new module would have to be
written just for the --chroot option.

In short, using the --chroot option if compiled with --with-libpam is
fine so long as it's actually run as root. As far as I know, emerge has
to be run as root (except for --pretend and searching).
 
Old 03-05-2010, 11:52 PM
"P. Levine"
 
Default emerge --root : users not created

Attached is, hopefully, the final version of the chroot patch for
shadow. In it, I've included chroot support for all relevant utilities.

Given that most of the utilities that use PAM do so for authentication
only, instead of disabling it when used with the --chroot flag, I've
moved the relevant code to run before chroot is called. It appears less
dependent on where it is called than I had first suspected.

The exception to this is passwd, chpasswd, and newusers which use PAM to
do the actual password encryption. I've altered these to fall back to
using shadow functions (the default when not compiled with PAM support)
while using --chroot. I'll admit it looks a little ugly, but it doesn't
seem like it can be helped. I have tested these, and they work fine
(though before using the --chroot flag, ideally, $ROOT/etc/login.defs
file should define the same encryption method as
$ROOT/etc/pam.d/system-auth).

Instead of having a whole lot of "if (chroot_flg)" tests scattered
throughout the source files, I've instead made ample use of the
"--wrap=" ldflag to wrap calls to pertinent libc functions into a
wrapper that checks if the chroot flag is set (still have to use the
"if (chroot_flg)" tests in passwd, chpasswd, and newusers, though).

Having examined how selinux is used in shadow, I had to disable its use
in useradd, userdel, and usermod when using chroot. It calls on execve
after alteration of the database files, which as far as i can tell,
would fail. And even if it was hacked to succeed, it would likely
either alter the build system or fail after trying load cross-compiled
libs. In any event, --chroot with selinux could only benefit a selinux
system cross-compiling a selinux system.

I've tested all related utilities with various arguments and found them
all functional, with and without the --chroot flag.

-- Peter Levine
 
Old 03-08-2010, 10:05 AM
Ed W
 
Default emerge --root : users not created

On 06/03/2010 00:52, P. Levine wrote:

I've tested all related utilities with various arguments and found them
all functional, with and without the --chroot flag.



This is fantastic development!

Ed W
 
Old 06-10-2010, 10:39 AM
Marcus Priesch
 
Default emerge --root : users not created

Hi Guys,

a time a go there was heavy discussion (and a solution) for this problem
on the mailinglist ...

hoever, now i would also need this behavior ...

as i found nothing in the archives as how to apply the forementioned
patch to useradd et al. my question is when will this be production
ready for the rest of the gentoo world ... and what can i do to use it
now ... or where can i help speeding up things ...

is there an overlay ?!?

after all --root and --config-root ROCKS !!!!

thanks a lot for all your hard work !!!

regards,
marcus.

btw: gentoo again won the race for my embedded linux boxes for measuring
weather data against ubuntu and debian because it's far more flexible
when it comes to ... everything (choosing kernel version, python
version, ebuild building )) - for external kernel modules ))
 
Old 06-11-2010, 08:17 AM
Sven Rebhan
 
Default emerge --root : users not created

Hey,

if you want to help here, try to get upstream shadow guys to accept
and commit the patch here:

https://alioth.debian.org/tracker/index.php?func=detail&aid=312407&group_id=30580&at id=411480

Have fun!

Sven
 
Old 06-11-2010, 03:08 PM
Marcus Priesch
 
Default emerge --root : users not created

Hi sven,

wouldnt it be enough to have the patch included in gentoo's shadow
ebuild - as i think its mainly relevant for gentoo folks - at least in
the meantime, until the patch gets accepted upstream ?!

as i assume this patch alone is not enough - as it needs tweaking the
eclass providing the eadduser & co functions also ... and therefore it's
hard to put in an overlay ... or ?!?!

regards,
m.

Am Freitag, den 11.06.2010, 10:17 +0200 schrieb Sven Rebhan:
> Hey,
>
> if you want to help here, try to get upstream shadow guys to accept
> and commit the patch here:
>
> https://alioth.debian.org/tracker/index.php?func=detail&aid=312407&group_id=30580&at id=411480
>
> Have fun!
>
> Sven
>
 
Old 06-14-2010, 08:09 AM
Sven Rebhan
 
Default emerge --root : users not created

2010/6/11 Marcus Priesch <marcus@priesch.priv.at>:
> Hi sven,
>
> wouldnt it be enough to have the patch included in gentoo's shadow
> ebuild - as i think its mainly relevant for gentoo folks - at least in
> the meantime, until the patch gets accepted upstream ?!

Well, talk to the Gentoo maintainer of the shadow suite. :-) IIRC, it was
clearly said, that the patch has to go through mainstream, but you can
try nevertheless. IMHO the patch really _should_ go upstream and be
reviewed there as it might be relevant for security stuff.

> as i assume this patch alone is not enough - as it needs tweaking the
> eclass providing the eadduser & co functions also ... and therefore it's
> hard to put in an overlay ... or ?!?!

The procedure would be:
1. Get the patch accepted either upstream or in the portage tree.
2. Find a good check to distinguish --chroot enabled and disabled shadow
3. Modify the eclass accordingly.

So, start with 1. and the rest will happen automatically... ;-)

Sven
 

Thread Tools




All times are GMT. The time now is 04:12 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org