On Thu, Sep 15, 2005 at 06:29:12AM -0500, Peter Samuelson wrote:
[Ernestas V.]
Perhaps hard/symlinking original /etc/passwd, /etc/shadow and
/etc/group to chrooted environments would help?
Symlinks won't work. Think about what a chroot environment *is*.
Hardlinks will only work if
On Sun, Sep 18, 2005 at 11:52:09PM -0400, Daniel Jacobowitz wrote:
Here's the code, hardcoded paths and all:
http://return.false.org/~drow/fuse/shadow-etc.c
Slightly better, but not much:
http://return.false.org/~drow/fuse/
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE,
On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote:
Is it possible to configure a set of chroots (woody, sarge, whatever)
so that all of the chroot passwd/group DBs will stay in sync with each
other and with the host DB automaticall, so that, for example, a
useradd, usermod, or
Perhaps hard/symlinking original /etc/passwd, /etc/shadow and /etc/group
to chrooted environments would help?
Rob Browning wrote:
Is it possible to configure a set of chroots (woody, sarge, whatever)
so that all of the chroot passwd/group DBs will stay in sync with each
other and with the
[Ernestas V.]
Perhaps hard/symlinking original /etc/passwd, /etc/shadow and
/etc/group to chrooted environments would help?
Symlinks won't work. Think about what a chroot environment *is*.
Hardlinks will only work if the programs that edit /etc/passwd and
/etc/group overwrite them rather
On Sep 15, Peter Samuelson [EMAIL PROTECTED] wrote:
Bind mounts will work
(mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd)
but apparently don't support locking all of a file's representations,
What about bind-mounting the /etc/.pwd.lock lock file too?
--
ciao,
Marco
signature.asc
On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote:
Is it possible to configure a set of chroots (woody, sarge, whatever)
so that all of the chroot passwd/group DBs will stay in sync with each
other and with the host DB automaticall, so that, for example, a
useradd, usermod, or
Ernestas V. [EMAIL PROTECTED] writes:
Perhaps hard/symlinking original /etc/passwd, /etc/shadow and /etc/group
to chrooted environments would help?
Thanks for the suggestion, but I suspect that locking wouldn't work
correctly in such an arrangement.
If you could tell the system to use a
Richard Atterer [EMAIL PROTECTED] writes:
From the adduser/addgroup manpage:
If the file /usr/local/sbin/adduser.local exists, it will be executed
after the user account has been set up in order to do any local setup.
The arguments passed to adduser.local are: username uid gid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Pollock [EMAIL PROTECTED] writes:
On Wed, Sep 14, 2005 at 02:12:54PM -0700, Rob Browning wrote:
Is it possible to configure a set of chroots (woody, sarge, whatever)
so that all of the chroot passwd/group DBs will stay in sync with each
Roger Leigh [EMAIL PROTECTED] writes:
Notice that the /etc/schroot/setup.d/30passwd was used to sync the
passwd and related files by copying them into the chroot from the main
system. While it's a simple copy in this case, you can easily
customise the script to sync the other way on session
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rob Browning [EMAIL PROTECTED] writes:
Roger Leigh [EMAIL PROTECTED] writes:
Notice that the /etc/schroot/setup.d/30passwd was used to sync the
passwd and related files by copying them into the chroot from the main
system. While it's a simple
Is it possible to configure a set of chroots (woody, sarge, whatever)
so that all of the chroot passwd/group DBs will stay in sync with each
other and with the host DB automaticall, so that, for example, a
useradd, usermod, or userdel, will automatically affect all of the DBs
simultaneously and
13 matches
Mail list logo
