On Mon, May 05, 2014 at 03:47:21PM +0200, Reindl Harald wrote:
>
>
> Am 05.05.2014 15:27, schrieb Richard W.M. Jones:
> > I think it would be better if we could declaratively say which user
> > accounts an RPM needs, and RPM can add or remove users from the system
> > based on this. eg. Apache h
Am 05.05.2014 15:27, schrieb Richard W.M. Jones:
> I think it would be better if we could declaratively say which user
> accounts an RPM needs, and RPM can add or remove users from the system
> based on this. eg. Apache httpd.spec would contain just:
>
> %user apache
> %group apache
>
> (T
On 05/05/2014 03:27 PM, Richard W.M. Jones wrote:
I think it would be better if we could declaratively say which user
accounts an RPM needs, and RPM can add or remove users from the system
based on this. eg. Apache httpd.spec would contain just:
%user apache
%group apache
And if we had
On Mon, Apr 28, 2014 at 05:15:59PM +, Colin Walters wrote:
> On Mon, Apr 28, 2014 at 12:45 PM, Tomasz Torcz
> wrote:
> >
> > Risking being totally offtopic, but would TCB solve all most of
> >this issues?
> >www.openwall.com/tcb/ or
> >http://www.openwall.com/presentations/Owl/mgp00020.html
On Wed, 2014-04-30 at 13:25 +, Colin Walters wrote:
> On Tue, Apr 29, 2014 at 11:23 PM, Simo Sorce wrote:
> >
> > can you use an actual chroot ?
>
> Calling chroot tends to imply running code from the target system. I'd
> prefer to avoid that by default. In practice some things are going
On Tue, Apr 29, 2014 at 11:23 PM, Simo Sorce wrote:
can you use an actual chroot ?
Calling chroot tends to imply running code from the target system. I'd
prefer to avoid that by default. In practice some things are going to
require it, but the more we can avoid it, the better.
I am not
On Mon, 2014-04-28 at 18:50 +, Colin Walters wrote:
> On Mon, Apr 28, 2014 at 1:39 PM, Simo Sorce wrote:
> >
> > We can do that with SSSD, which we are planning to take over all users
> > (though it will leave /etc/passwd on the system for emergency repair
> > and
> > backward compatibility)
On Mon, Apr 28, 2014 at 1:39 PM, Simo Sorce wrote:
We can do that with SSSD, which we are planning to take over all users
(though it will leave /etc/passwd on the system for emergency repair
and
backward compatibility).
Ok, though one thing that's going to be important to me at least is the
On Mon, 2014-04-28 at 17:15 +, Colin Walters wrote:
> On Mon, Apr 28, 2014 at 12:45 PM, Tomasz Torcz
> wrote:
> >
> > Risking being totally offtopic, but would TCB solve all most of
> > this issues?
> > www.openwall.com/tcb/ or
> > http://www.openwall.com/presentations/Owl/mgp00020.html
On Mon, Apr 28, 2014 at 12:45 PM, Tomasz Torcz
wrote:
Risking being totally offtopic, but would TCB solve all most of
this issues?
www.openwall.com/tcb/ or
http://www.openwall.com/presentations/Owl/mgp00020.html
It helps a little, but the problem here is not exactly about the
underlying
On Mon, Apr 28, 2014 at 11:52 AM, Simo Sorce wrote:
- How do you deal with conflicts ?
- What happen when an admin legitimately just use vipw and adds a
system
user in /etc/passwd instead of one of the other 2 you mention ?
- How do you propose to resolve users from multiple files ?
The ans
On Mon, 28 Apr 2014, Simo Sorce wrote:
On Mon, 2014-04-28 at 15:32 +, Colin Walters wrote:
On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters
wrote:
> For the fedora-atomic work, the only not-in-Fedora package is
> shadow-utils because it requires a patch, that still lives in my
> walters/rpm-o
On Mon, Apr 28, 2014 at 11:52:20AM -0400, Simo Sorce wrote:
> On Mon, 2014-04-28 at 15:32 +, Colin Walters wrote:
> > On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters
> > wrote:
> > > For the fedora-atomic work, the only not-in-Fedora package is
> > > shadow-utils because it requires a patch,
On Mon, 28.04.14 15:32, Colin Walters (walt...@verbum.org) wrote:
> On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters
> wrote:
> >For the fedora-atomic work, the only not-in-Fedora package is
> >shadow-utils because it requires a patch, that still lives in my
> >walters/rpm-ostree COPR.
>
> I attem
On Mon, 2014-04-28 at 15:32 +, Colin Walters wrote:
> On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters
> wrote:
> > For the fedora-atomic work, the only not-in-Fedora package is
> > shadow-utils because it requires a patch, that still lives in my
> > walters/rpm-ostree COPR.
>
> I attempted
On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters
wrote:
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
I attempted to capture some of this discussion here:
https://bugzilla.gnome.org/show_bu
On Mon, Apr 14, 2014 at 1:43 AM, Jan Zelený wrote:
1) What if I don't use systemd to start whatever program needs the
updated
data? (might not be a daemon for example)
Right, for say Evolution which runs in a user session, it obviously has
to do any mail format migrations when it starts in
On 11. 4. 2014 at 17:08:49, Colin Walters wrote:
> On Fri, Apr 11, 2014 at 1:05 PM, Miloslav Trmač wrote:
> > So, having /usr/lib/passwd storing the same limited set of data is
> > not the right long-term thing. Unfortunately, AFAIK the fuller
> > interface isn't ready yet.
>
> Yeah, it'd be nic
On 04/11/2014 05:19 PM, Lennart Poettering wrote:
On Fri, 11.04.14 19:05, Miloslav Trmač (m...@volny.cz) wrote:
There is broad agreement that future access to the user database database
(both reading and writing) will be through sssd[1], and that the data model
of /etc/{passwd,shadow} is too r
On Fri, Apr 11, 2014 at 12:09 PM, Colin Walters
wrote:
On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
wrote:
>
> If you move in this direction, you have to create files/dirs to be
> owned by the daemon user too.
If we ban set{u,g}id binaries for dynamic uids, then we can just have
all f
2014-04-11 19:19 GMT+02:00 Lennart Poettering :
> On Fri, 11.04.14 19:05, Miloslav Trmač (m...@volny.cz) wrote:
>
> > There is broad agreement that future access to the user database database
> > (both reading and writing) will be through sssd[1], and that the data
> model
> > of /etc/{passwd,shad
On Fri, 11.04.14 19:05, Miloslav Trmač (m...@volny.cz) wrote:
> There is broad agreement that future access to the user database database
> (both reading and writing) will be through sssd[1], and that the data model
> of /etc/{passwd,shadow} is too restrictive--we already want/need to store
> more
On Fri, 2014-04-11 at 19:01 +0200, Lennart Poettering wrote:
> On Fri, 11.04.14 12:47, Simo Sorce (s...@redhat.com) wrote:
>
> > > So how about this then, we have a drop-in dir in /usr as above, with
> > > files that list the numeric UID where possible. For the cases where
> > > that's not possibl
On Fri, Apr 11, 2014 at 1:05 PM, Miloslav Trmač wrote:
So, having /usr/lib/passwd storing the same limited set of data is
not the right long-term thing. Unfortunately, AFAIK the fuller
interface isn't ready yet.
Yeah, it'd be nice to merge the accountsservice database in to the
system db.
On Fri, Apr 11, 2014 at 12:49 PM, Lennart Poettering
wrote:
> On Fri, 11.04.14 16:09, Colin Walters (walt...@verbum.org) wrote:
>
>> On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
>> wrote:
>> >
>> >If you move in this direction, you have to create files/dirs to be
>> >owned by the daemon user
2014-04-11 8:33 GMT+02:00 Colin Walters :
> For the fedora-atomic work, the only not-in-Fedora package is shadow-utils
> because it requires a patch, that still lives in my walters/rpm-ostree COPR.
>
> Patch is linked from my post here:
> http://lists.alioth.debian.org/pipermail/pkg-shadow-
> deve
On Fri, 11.04.14 12:47, Simo Sorce (s...@redhat.com) wrote:
> > So how about this then, we have a drop-in dir in /usr as above, with
> > files that list the numeric UID where possible. For the cases where
> > that's not possible however, we'd check some additional db in /var. If
> > that db doesn'
On 11 April 2014 10:49, Lennart Poettering wrote:
> On Fri, 11.04.14 16:09, Colin Walters (walt...@verbum.org) wrote:
>
> > On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
> > wrote:
> > >
> > >If you move in this direction, you have to create files/dirs to be
> > >owned by the daemon user too
On Fri, 11.04.14 16:09, Colin Walters (walt...@verbum.org) wrote:
> On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
> wrote:
> >
> >If you move in this direction, you have to create files/dirs to be
> >owned by the daemon user too.
Hmm, let's think for a moment what kind of files this actually
On Fri, 2014-04-11 at 18:39 +0200, Lennart Poettering wrote:
> On Fri, 11.04.14 15:49, Colin Walters (walt...@verbum.org) wrote:
>
> > On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
> > wrote:
> > >
> > >I am really not convinced that this is a good idea and will really
> > >fly. Having a f
On Fri, 11.04.14 15:49, Colin Walters (walt...@verbum.org) wrote:
> On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
> wrote:
> >
> >I am really not convinced that this is a good idea and will really
> >fly. Having a fully static passwd file can't really work since admins
> >must have the abi
On Fri, 2014-04-11 at 16:09 +, Colin Walters wrote:
> On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
> wrote:
> >
> > If you move in this direction, you have to create files/dirs to be
> > owned by the daemon user too.
>
> That's a really good point. I hadn't thought about that. Urgh.
On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
wrote:
If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.
That's a really good point. I hadn't thought about that. Urgh. The
way this works in the RPM world is so evil - rpm calls out to
/usr/
On 04/11/2014 03:27 PM, Lennart Poettering wrote:
For me the "factory" systemd stuff is actually very much about
containers. It's actually kinda my primary goal here: I want to allow
deployment of a single /usr in a thousnad containers, so that each
container's /etc and /var is automatically pop
On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
wrote:
I am really not convinced that this is a good idea and will really
fly. Having a fully static passwd file can't really work since admins
must have the ability to change certain user attributes for certain
system users. This is quite ob
On 04/11/2014 03:22 PM, Lennart Poettering wrote:
On Fri, 11.04.14 15:05, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 04/11/2014 02:47 PM, Lennart Poettering wrote:
/etc is "administrator space" and evolving into "administrator only
space" which means eventually nothing will be placin
On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters wrote:
> One way to fix this that goes with my general direction of moving things out
> of %post into systemd: a dynamic uid reservation system that saves state
> persistently.
> Crudely, this would be ExecStartPre=/usr/sbin/useradd -r ...
> except we
On Fri, 11.04.14 15:19, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
> On 04/11/2014 03:11 PM, drago01 wrote:
> >On Fri, Apr 11, 2014 at 5:05 PM, "Jóhann B. Guðmundsson"
> > wrote:
> >>On 04/11/2014 02:47 PM, Lennart Poettering wrote:
> >>>On Fri, 11.04.14 14:41, Jóhann B. Guðmundsson (joh
On Fri, 11.04.14 15:05, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
> On 04/11/2014 02:47 PM, Lennart Poettering wrote:
> >On Fri, 11.04.14 14:41, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
> >
> >>On 04/11/2014 02:34 PM, Lennart Poettering wrote:
> >>>Within the systemd project we
On 04/11/2014 03:11 PM, drago01 wrote:
On Fri, Apr 11, 2014 at 5:05 PM, "Jóhann B. Guðmundsson"
wrote:
On 04/11/2014 02:47 PM, Lennart Poettering wrote:
On Fri, 11.04.14 14:41, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 04/11/2014 02:34 PM, Lennart Poettering wrote:
Within the sy
On Fri, Apr 11, 2014 at 5:05 PM, "Jóhann B. Guðmundsson"
wrote:
>
> On 04/11/2014 02:47 PM, Lennart Poettering wrote:
>>
>> On Fri, 11.04.14 14:41, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>>
>>> On 04/11/2014 02:34 PM, Lennart Poettering wrote:
Within the systemd project we hav
On 04/11/2014 02:47 PM, Lennart Poettering wrote:
On Fri, 11.04.14 14:41, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 04/11/2014 02:34 PM, Lennart Poettering wrote:
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descrip
On Fri, 11.04.14 14:41, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
> On 04/11/2014 02:34 PM, Lennart Poettering wrote:
> >Within the systemd project we have been working on a scheme we call
> >"factory" where packages can drop in static descriptions in /usr/lib of
> >stuff they need in /
On 04/11/2014 02:34 PM, Lennart Poettering wrote:
Within the systemd project we have been working on a scheme we call
"factory" where packages can drop in static descriptions in /usr/lib of
stuff they need in /etc and /var to work properly. The idea is to then
use this information automatically
On Fri, 11.04.14 06:33, Colin Walters (walt...@verbum.org) wrote:
> For the fedora-atomic work, the only not-in-Fedora package is
> shadow-utils because it requires a patch, that still lives in my
> walters/rpm-ostree COPR.
>
> Patch is linked from my post here:
> http://lists.alioth.debian.org/p
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
Patch is linked from my post here:
http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html
Also, some discussion in t
46 matches
Mail list logo
