Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Russ Allbery]

Benjamin Kaduk  writes:
> On Wed, Nov 30, 2016 at 08:55:02PM -0300, Felipe Sateler wrote:

>> Well, this command imports an environment variable from the current
>> environment into the systemd --user one. Therefore, it would need to be
>> run after each time that environment variable is set...

> So, libpam_krb5?

Urk.  I definitely want to avoid forking external programs in PAM modules
if possible.

Isn't there a way to configure a set of environment variables that are
automatically populated into the systemd user environment from the user's
session?  I mean, this stuff is all set up at login, which I assume is
before systemd --user spawns.

-- 
Russ Allbery (r...@debian.org)   

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Benjamin Kaduk]

On Wed, Nov 30, 2016 at 08:55:02PM -0300, Felipe Sateler wrote:
> On 30 November 2016 at 20:39, Russ Allbery  wrote:
> >
> > Apologies for my lack of knowledge of systemd in user mode -- it's really
> > neat but I haven't had a chance to play with it yet.  Who would run this
> > command?  Is it something that libpam-afs-session would run from a
> > postinst maintainer script, or is it something more complicated than that?
> 
> Well, this command imports an environment variable from the current
> environment into the systemd --user one. Therefore, it would need to
> be run after each time that environment variable is set...

So, libpam_krb5?

-Ben

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Felipe Sateler]

On 30 November 2016 at 20:39, Russ Allbery  wrote:
> Felipe Sateler  writes:
>> On 30 November 2016 at 19:20, Michael Biebl  wrote:
>>> Am 30.11.2016 um 23:12 schrieb Russ Allbery:
>
 Anyway, it certainly could be registered in -noninteractive (there was
 some reason why I didn't do that), but I think the Kerberos ticket
 cache problem will still be an issue.  Is there some mechanism to
 convey the value of KRB5CCNAME from the user's login environment to
 systemd --user?
>
>>> systemctl --user set-environment
>>> might be what you are looking for.
>
>> `systemctl --user import-environment KRB5CCNAME` might be more
>> appropriate if this variable should be copied from an already existing
>> environment.
>
> Apologies for my lack of knowledge of systemd in user mode -- it's really
> neat but I haven't had a chance to play with it yet.  Who would run this
> command?  Is it something that libpam-afs-session would run from a
> postinst maintainer script, or is it something more complicated than that?

Well, this command imports an environment variable from the current
environment into the systemd --user one. Therefore, it would need to
be run after each time that environment variable is set...

-- 

Saludos,
Felipe Sateler

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Benjamin Kaduk]

On Wed, Nov 30, 2016 at 07:31:24PM -0300, Felipe Sateler wrote:
> 
> `systemctl --user import-environment KRB5CCNAME` might be more
> appropriate if this variable should be copied from an already existing
> environment.

But when would this run, and what package would be responsible for causing
it to be run?  (I would prefer to not require that the user is responsible
for causing it to be run.)


Michael Biebl  writes:

> This was mentiond on IRC:
>
> >  afaik, AFS tokens are stored as special keys in the
> > keyring, nowadays... so it might work if afs was patched to look in
> > the 'user' keyring, or if regular logins somehow joined systemd's
> > session keyring instead of creating a new one
> >  (CIFS has the same problem)

The AFS tokens are scoped to a specific PAG (Process Authentication Group),
which can provide cross-process isolation.  Processes can request to be
put in a new PAG explicitly if they desire separation, and PAGS are
identified by the afs_pag key type in the session keyring.  We generally
don't want to use the user keyring since that could lead to neutering of
the cross-process isolation that the PAGs are expected to provide.

-Ben

P.S. Looking more closely at the linked google doc, it was more likely
to be Jonathan Billings than Dave Botsch who wrote it.

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Russ Allbery]

Felipe Sateler  writes:
> On 30 November 2016 at 19:20, Michael Biebl  wrote:
>> Am 30.11.2016 um 23:12 schrieb Russ Allbery:

>>> Anyway, it certainly could be registered in -noninteractive (there was
>>> some reason why I didn't do that), but I think the Kerberos ticket
>>> cache problem will still be an issue.  Is there some mechanism to
>>> convey the value of KRB5CCNAME from the user's login environment to
>>> systemd --user?

>> systemctl --user set-environment
>> might be what you are looking for.

> `systemctl --user import-environment KRB5CCNAME` might be more
> appropriate if this variable should be copied from an already existing
> environment.

Apologies for my lack of knowledge of systemd in user mode -- it's really
neat but I haven't had a chance to play with it yet.  Who would run this
command?  Is it something that libpam-afs-session would run from a
postinst maintainer script, or is it something more complicated than that?

-- 
Russ Allbery (r...@debian.org)   

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#845185: init-system-helpers: deb-system-invoke starts disabled systemd service on package install/upgrade (backport request)

[Felipe Sateler]

On 21 November 2016 at 05:37, Yury V. Zaytsev  wrote:
> Package: init-system-helpers
> Version: 1.22
> Severity: important
>
> Hi,
>
> In short, on Jessie, when a systemd-only package is installed and/or
> upgraded, the service is started even when disabled, which is a very
> annoying and unsafe behavior; please refer to the original bug for the
> details: #768456. The bug was fixed and the fix has been out in the wild for
> quite some time, but, very unfortunately, it didn't make it into Jessie.
>
> I'm filing this bug as discussed on #debian-systemd, requesting to kindly
> backport the relevant commit and push the new package to -updates:
>
> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=a4e43fcdabf7962d2a765b6b0e11a51734afb5f0

I've been thinking about this, and the fix would be incomplete without
addressing #768450 too. Unfortunately, this means also an update of
src:sysvinit (as invoke-rc.d was moved to i-s-h post-jessie) is needed
but I don't really want to touch that...

-- 

Saludos,
Felipe Sateler

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Processed: notfound 827191 in 1.22, found 827191 in 1.25

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> notfound 827191 1.22
Bug #827191 {Done: Martin Pitt } [init-system-helpers] 
invoke-rc.d don't start systemd services
No longer marked as found in versions init-system-helpers/1.22.
> found 827191 1.25
Bug #827191 {Done: Martin Pitt } [init-system-helpers] 
invoke-rc.d don't start systemd services
Marked as found in versions init-system-helpers/1.25.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
827191: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827191
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Martin Pitt]

Control: tag -1 pending

Bonsoir Laurent,

Laurent Bigonville [2016-11-30 21:13 +0100]:
> I quickly retested with that rules file and plymouth seems happy with it.

Cool, thanks!

  https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=4f6f3035b9

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Processed: Re: Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #756109 [systemd] systemd: Please copy 70-uaccess.rules and 71-seat.rules 
in the initramfs
Added tag(s) pending.

-- 
756109: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756109
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Processed: fixed 845185 in 1.23

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed 845185 1.23
Bug #845185 [init-system-helpers] init-system-helpers: deb-system-invoke starts 
disabled systemd service on package install/upgrade (backport request)
Marked as fixed in versions init-system-helpers/1.23.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
845185: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845185
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Felipe Sateler]

On 30 November 2016 at 19:20, Michael Biebl  wrote:
> Am 30.11.2016 um 23:12 schrieb Russ Allbery:
>> Anyway, it certainly could be registered in -noninteractive (there was
>> some reason why I didn't do that), but I think the Kerberos ticket cache
>> problem will still be an issue.  Is there some mechanism to convey the
>> value of KRB5CCNAME from the user's login environment to systemd --user?
>
> systemctl --user set-environment
> might be what you are looking for.

`systemctl --user import-environment KRB5CCNAME` might be more
appropriate if this variable should be copied from an already existing
environment.


-- 

Saludos,
Felipe Sateler

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Michael Biebl]

Am 30.11.2016 um 23:20 schrieb Michael Biebl:
> Am 30.11.2016 um 23:12 schrieb Russ Allbery:
>> It's a little weird to me that systemd --user loads
>> common-session-interactive and then apparently starts xterms in this
>> particular situation.  Those are kind of interactive.  But presumably it's
>> assuming xterm will open its own interactive session?
> 
> We originally used common-session.
> See #739676 for why this was changed

Fwiw, the processes started by systemd --user are not really
interactive. See dconf for example.
xterm is not started as a user service. I assume you meant the
gnome-terminal-server.service user service, which is the background
process and for which gnome-terminal is a frontend.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Michael Biebl]

Am 30.11.2016 um 23:12 schrieb Russ Allbery:
> It's a little weird to me that systemd --user loads
> common-session-interactive and then apparently starts xterms in this
> particular situation.  Those are kind of interactive.  But presumably it's
> assuming xterm will open its own interactive session?

We originally used common-session.
See #739676 for why this was changed

> Anyway, it certainly could be registered in -noninteractive (there was
> some reason why I didn't do that), but I think the Kerberos ticket cache
> problem will still be an issue.  Is there some mechanism to convey the
> value of KRB5CCNAME from the user's login environment to systemd --user?

systemctl --user set-environment
might be what you are looking for.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Russ Allbery]

Felipe Sateler  writes:
> On 30 November 2016 at 17:30, Russ Allbery  wrote:

>> I don't suppose there's any way to get systemd --user to open a PAM
>> session on behalf of the user before starting to run programs?  That
>> would probably solve the problem (although there may still be some
>> complications in making sure it has correct visibility to the Kerberos
>> ticket cache).

> systemd --user does open a pam session (with the systemd-user name).
> Maybe the problem is that libpam-afs-session (is this the right
> module?) registers itself in the common-session include file but
> systemd-user loads only common-session-noninteractive ?

That's the right module.  Hm, yeah, it's probably a combination of that
plus the fact that it doesn't know how to find the Kerberos ticket cache
and therefore can't get a token.

It's a little weird to me that systemd --user loads
common-session-interactive and then apparently starts xterms in this
particular situation.  Those are kind of interactive.  But presumably it's
assuming xterm will open its own interactive session?

Anyway, it certainly could be registered in -noninteractive (there was
some reason why I didn't do that), but I think the Kerberos ticket cache
problem will still be an issue.  Is there some mechanism to convey the
value of KRB5CCNAME from the user's login environment to systemd --user?

-- 
Russ Allbery (r...@debian.org)   

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Felipe Sateler]

On 30 November 2016 at 17:30, Russ Allbery  wrote:
>
> Michael Biebl  writes:
>
> > Should we assign this to openafs? Is there something which needs to be
> > done on the systemd side, and if so, further information and help would
> > be welcome.
>
> I don't suppose there's any way to get systemd --user to open a PAM
> session on behalf of the user before starting to run programs?  That would
> probably solve the problem (although there may still be some complications
> in making sure it has correct visibility to the Kerberos ticket cache).

systemd --user does open a pam session (with the systemd-user name).
Maybe the problem is that libpam-afs-session (is this the right
module?) registers itself in the common-session include file but
systemd-user loads only common-session-noninteractive ?


-- 

Saludos,
Felipe Sateler

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Michael Biebl]

Am 30.11.2016 um 21:42 schrieb Benjamin Kaduk:
> On Wed, Nov 30, 2016 at 09:11:58PM +0100, Michael Biebl wrote:
>> Am 30.11.2016 um 20:01 schrieb Dirk Heinrichs:
>>
>> Afaics, this will affect any service which was started as a systemd
>> --user service. dbus is just one of them.
> 
> I have not absorbed the full report yet, but wanted to note that Dave Botsch 
> (IIRC)
> put together some notes on using AFS with systemd --user at:
> https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKtI-Qh00c5_9zJa4YHjnpB6ODM/pub

Just a quick side-note while reading that document:

> Unfortunately, to get the service to start when you log in, you need to 
> set up systemd --user directories and symlinks.  
> 
> Create a $HOME/.config/systemd/user/default.target.wants directory
> Create a symlink in that directory to /etc/systemd/user/aklog.service

You can just add a

[Install]
WantedBy=default.target

to the service file and then run systemctl enable --user aklog.service
This will make sure to create all necessary directories and symlinks.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Benjamin Kaduk]

On Wed, Nov 30, 2016 at 09:11:58PM +0100, Michael Biebl wrote:
> Am 30.11.2016 um 20:01 schrieb Dirk Heinrichs:
> 
> Afaics, this will affect any service which was started as a systemd
> --user service. dbus is just one of them.

I have not absorbed the full report yet, but wanted to note that Dave Botsch 
(IIRC)
put together some notes on using AFS with systemd --user at:
https://docs.google.com/document/d/1P27fP1uj-C8QdxDKMKtI-Qh00c5_9zJa4YHjnpB6ODM/pub

-Ben

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Russ Allbery]

Michael Biebl  writes:

> Should we assign this to openafs? Is there something which needs to be
> done on the systemd side, and if so, further information and help would
> be welcome.

I don't suppose there's any way to get systemd --user to open a PAM
session on behalf of the user before starting to run programs?  That would
probably solve the problem (although there may still be some complications
in making sure it has correct visibility to the Kerberos ticket cache).

-- 
Russ Allbery (r...@debian.org)   

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Michael Biebl]

Am 30.11.2016 um 20:01 schrieb Dirk Heinrichs:
> Package: systemd
> Version: 232-6
> Severity: important
> 
> --- Please enter the report below this line. ---
> I'm running systems with user home directories located in an OpenAFS
> network filesystem. This used to work fine for years. However, since
> some time now, some desktop environments/applications (KDE, Evolution,
> etc.) have trouble writing their config files, while writing to the
> same file from within a shell worked fine.
> 
> I did some investigation and found out that dbus-daemon is not started
> be the pam-authenticated user session anymore, but
> via /lib/systemd/systemd --user.
> 
> This in itself wouldn't be a problem, but /lib/systemd/systemd --user
> has been started by PID 1 and thus doesn't run with an AFS token, which
> means that all processes spawned from it don't have one either:
> 
> testuser 2013 1  0 18:54 ?00:00:00 /lib/systemd/systemd
> --user
> testuser 2015  2013  0 18:54 ?00:00:00 (sd-pam)
> testuser 7783  2013  0 19:29 ?00:00:01 /usr/bin/dbus-daemon
> --session --address=systemd: --nofork --nopidfile --systemd-activation
> 
> This means that any application that wants to access files through dbus
> fails to do so, for example:

Afaics, this will affect any service which was started as a systemd
--user service. dbus is just one of them.

This was mentiond on IRC:

>  afaik, AFS tokens are stored as special keys in the
> keyring, nowadays... so it might work if afs was patched to look in
> the 'user' keyring, or if regular logins somehow joined systemd's
> session keyring instead of creating a new one
>  (CIFS has the same problem)

So this looks like something the openafs maintainers have to look into,
I've CCed their maintainers for their input.

Should we assign this to openafs? Is there something which needs to be
done on the systemd side, and if so, further information and help would
be welcome.

Regards,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Laurent Bigonville]

Le 30/11/16 à 14:23, Martin Pitt a écrit :

Laurent Bigonville [2016-11-30 12:58 +0100]:

Is it a problem if loginctl is not present in the initramfs? Would the rule
be executed later in the boot again?

Yes, the rules are being executed on all devices later on, though
systemd-udev-trigger.service (usually dubbed "coldplugging").

IMHO putting logind into the initrd would just be plain wrong and
bloat. That is not the initrd's job.

That said, adding only 71-seat.rules to the initrd seems okay to me,
even though it smells like a workaround. Is that sufficient for
plymouth's needs?


I quickly retested with that rules file and plymouth seems happy with it.

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

systemd_232-7_amd64.changes is NEW

[Debian FTP Masters]

binary:libnss-systemd is NEW.
binary:libnss-systemd is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Michael Biebl]

Am 30.11.2016 um 20:01 schrieb Dirk Heinrichs:
> Package: systemd
> Version: 232-6
> Severity: important
> 
> --- Please enter the report below this line. ---
> I'm running systems with user home directories located in an OpenAFS
> network filesystem. This used to work fine for years. However, since
> some time now, some desktop environments/applications (KDE, Evolution,
> etc.) have trouble writing their config files, while writing to the
> same file from within a shell worked fine.
> 
> I did some investigation and found out that dbus-daemon is not started
> be the pam-authenticated user session anymore, but
> via /lib/systemd/systemd --user.

How is this AFS token set? Is it an environment variable?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#846377: [systemd] /lib/systemd/systemd --user starts dbus-daemon without AFS token

[Dirk Heinrichs]

Package: systemd
Version: 232-6
Severity: important

--- Please enter the report below this line. ---
I'm running systems with user home directories located in an OpenAFS
network filesystem. This used to work fine for years. However, since
some time now, some desktop environments/applications (KDE, Evolution,
etc.) have trouble writing their config files, while writing to the
same file from within a shell worked fine.

I did some investigation and found out that dbus-daemon is not started
be the pam-authenticated user session anymore, but
via /lib/systemd/systemd --user.

This in itself wouldn't be a problem, but /lib/systemd/systemd --user
has been started by PID 1 and thus doesn't run with an AFS token, which
means that all processes spawned from it don't have one either:

testuser 2013 1  0 18:54 ?00:00:00 /lib/systemd/systemd
--user
testuser 2015  2013  0 18:54 ?00:00:00 (sd-pam)
testuser 7783  2013  0 19:29 ?00:00:01 /usr/bin/dbus-daemon
--session --address=systemd: --nofork --nopidfile --systemd-activation

This means that any application that wants to access files through dbus
fails to do so, for example:

(evolution:9447): dconf-WARNING **: failed to commit changes to dconf:
GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code2:
Cannot open dconf database: Failed to open file
'/afs/altum.de/home/testuser/.config/dconf/user': Permission denied

To verify, I added an AFS ACL entry to each sub-directory of testuser's
home, which allowed write access for system:anyuser. Afterwards, the
errors were gone.

Of course, it's not a solution to grant unauthenticated
users write access to every user's home directory.

So, in it's current form, this setup makes most desktop environments
simply unusable.

--- System information. ---
Architecture: Kernel:   Linux 4.8.0-1-amd64

Debian Release: stretch/sid
  990 testing www.deb-multimedia.org   990 testing
ftp.de.debian.org   500 syncthing   apt.syncthing.net   500 stable
update.devolo.com   500 stable  repo.saltstack.com
--- Package information. ---
Depends   (Version) | Installed
===-+-=
libacl1   (>= 2.2.51-8) | 2.2.52-3
libapparmor1  (>= 2.9.0-3+exp2) | 2.10.95-6
libaudit1  (>= 1:2.2.1) | 1:2.6.7-1
libblkid1   (>= 2.19.1) | libc6
(>= 2.17) | libcap2 (>= 1:2.10) |
libcryptsetup4 (>= 2:1.4.3) | libgcrypt20
   (>= 1.7.0) | libgpg-error0 (>= 1.14) |
libidn11  (>= 1.13) | libip4tc0
  | libkmod2(>= 5~) |
liblz4-1  (>= 0.0~r127) | liblzma5   (>=
5.1.1alpha+20120614) | libmount1   (>= 2.26.2) |
libpam0g  (>= 0.99.7.1) | libseccomp2
   (>= 2.3.1) | libselinux1  (>= 2.1.9) |
libsystemd0   (= 232-6) | util-linux
  (>= 2.27.1) | mount (>= 2.26) |
adduser |

Package Status   (Version) | Installed
==-+-===
udev   | 232-6
dracut | initramfs-tools| 0.125


Recommends  (Version) | Installed
=-+-===
libpam-systemd| 232-6
dbus  | 1.10.12-1


Suggests   (Version) | Installed
-+-===
systemd-ui   | systemd-container| 232-6
policykit-1  | 0.105-17



--- Output from package bug script ---




-- 
Dirk Heinrichs 
GPG Public Key CB614542 | Jabber: dirk.heinri...@altum.de
Tox: he...@toxme.se
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Don Armstrong]

On Wed, 30 Nov 2016, Klaus Ethgen wrote:
> No, it worked well for decades and it was exactly why you have small
> root and resizable /usr on other medias.

It worked because of extraordinary effort by DDs to continuously migrate
libraries from /usr to / any time a binary or library in /bin, /sbin, or
/lib grew a new feature.

And that's not why it existed in the first place, either. See:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

And you can still have them split; you just need an initrd. You can even
use something tiny, like: https://github.com/chris-se/tiny-initramfs

> It start getting broken when systemd start taking over the world.

Correlation is not causation. It has been broken multiple times over the
past two decades. Debian has just stopped supporting it after the switch
to systemd.

> Well, why should it have too many changes? It works great. And it is
> that well-hung that there is simply not to much to change.

If that's the case, you'd think that someone who actually wanted SysV to
be supported going forward would step up and maintain it. But no one
has. So either it's not such a small amount of work, no one who can do
the work is interested in maintaining SysV any longer, or no one knows
that they should be doing the work.

This is Debian. If you want SysV maintained, you should do the work.

-- 
Don Armstrong  https://www.donarmstrong.com

2: There is no out. There is only in.
  -- "The Prisoner (2009 Miniseries)"

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#824532: udev: Include udev rules for more U2F devices

[Michael Biebl]

Am 13.11.2016 um 23:57 schrieb Michael Biebl:
> Am 13.11.2016 um 16:06 schrieb Michael Biebl:
>> Am 13.11.2016 um 07:46 schrieb Simon Josefsson:
>>> Hi. The udev file is needed by all applications using u2f, and not all
>>> uses libu2f-host. For example, chromium needs the udev rule to work. It
>>> just needs to be present on all systems for u2f to work. Alternatively,
>>> every package that wants to talk to a u2f device needs to ship the file
>>> which doesn't scale very well. 
>>
>> Or such applications depend on a libu2f-common package.
>>
> 
> Btw, splitting out the udev rules from the libu2f-host0 library package
> seems like something you should do in any case. Otherwise it makes
> soname bumps needlessly complicated as the two library packages need to
> conflict with each other.

I've talked to Martin Pitt on IRC and we agreed that splitting out the
udev rules is our preferred way to go here.

I've filed #846358 and #846359 for that.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Processing of systemd_232-7_amd64.changes

[Debian FTP Masters]

systemd_232-7_amd64.changes uploaded successfully to localhost
along with the files:
  systemd_232-7.dsc
  systemd_232-7.debian.tar.xz
  libnss-myhostname-dbgsym_232-7_amd64.deb
  libnss-myhostname_232-7_amd64.deb
  libnss-mymachines-dbgsym_232-7_amd64.deb
  libnss-mymachines_232-7_amd64.deb
  libnss-resolve-dbgsym_232-7_amd64.deb
  libnss-resolve_232-7_amd64.deb
  libnss-systemd-dbgsym_232-7_amd64.deb
  libnss-systemd_232-7_amd64.deb
  libpam-systemd-dbgsym_232-7_amd64.deb
  libpam-systemd_232-7_amd64.deb
  libsystemd-dev_232-7_amd64.deb
  libsystemd0-dbgsym_232-7_amd64.deb
  libsystemd0_232-7_amd64.deb
  libudev-dev-dbgsym_232-7_amd64.deb
  libudev-dev_232-7_amd64.deb
  libudev1-dbgsym_232-7_amd64.deb
  libudev1-udeb_232-7_amd64.udeb
  libudev1_232-7_amd64.deb
  systemd-container-dbgsym_232-7_amd64.deb
  systemd-container_232-7_amd64.deb
  systemd-coredump-dbgsym_232-7_amd64.deb
  systemd-coredump_232-7_amd64.deb
  systemd-dbgsym_232-7_amd64.deb
  systemd-journal-remote-dbgsym_232-7_amd64.deb
  systemd-journal-remote_232-7_amd64.deb
  systemd-sysv_232-7_amd64.deb
  systemd_232-7_amd64.buildinfo
  systemd_232-7_amd64.deb
  udev-dbgsym_232-7_amd64.deb
  udev-udeb_232-7_amd64.udeb
  udev_232-7_amd64.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Martin Pitt]

Laurent Bigonville [2016-11-30 12:58 +0100]:
> Is it a problem if loginctl is not present in the initramfs? Would the rule
> be executed later in the boot again?

Yes, the rules are being executed on all devices later on, though
systemd-udev-trigger.service (usually dubbed "coldplugging").

IMHO putting logind into the initrd would just be plain wrong and
bloat. That is not the initrd's job.

That said, adding only 71-seat.rules to the initrd seems okay to me,
even though it smells like a workaround. Is that sufficient for
plymouth's needs?

> Same question for systemd-sysctl. Couldn't that one be added in the
> initramfs?

Please not. It already gets run during boot, so it's again just
redundant and bloat for the initrd stage.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Laurent Bigonville]

On Fri, 13 Nov 2015 17:03:46 +0100 Laurent Bigonville  
wrote:

> On Sun, 29 Mar 2015 05:30:23 +0200 m...@linux.it (Marco d'Itri) wrote:
> > On Jul 26, Laurent Bigonville  wrote:
> >
> > > Do you think that it could be possible to copy 70-uaccess.rules and
> > > 71-seat.rules (and maybe 73-seat-late.rules) in the initramfs?
> > Adding 70-uaccess.rules is easy, but 71-seat.rules runs some programs
> > like loginctl which is not available in the initramfs.
> > Maybe we need a simpler rules file just for the initramfs?
> > Is this change still needed?
> > What do other distributions do about this?
>
> Still would be nice to have yes.
>
> I see two RUN in the 71-seat.rules and the loginctl one is used to lock
> the session in case a keylogger is inserted while the machine is booted,
> is it a problem if the command fails? The other one is udevadm, isn't
> this one already in the initramfs?
>
> Looking at fedora, I see that they are copying the following rules:
>
> inst_rules \
> 70-uaccess.rules \
> 71-seat.rules \
> 73-seat-late.rules \
> 90-vconsole.rules \
> 99-systemd.rules
>
> but indeed they are also installing the loginctl apparently (and
> systemd-sysctl for 99-systemd.rules).

What could be done here?

Is it a problem if loginctl is not present in the initramfs? Would the 
rule be executed later in the boot again?


Same question for systemd-sysctl. Couldn't that one be added in the 
initramfs?


___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Julian Andres Klode]

On Wed, Nov 30, 2016 at 09:45:08AM +0100, Klaus Ethgen wrote:
> Am Mi den 30. Nov 2016 um  9:36 schrieb Julian Andres Klode:
> > In your imagination, that is (yes, I too can write stupid replies
> > without any arguments - but I actually can provide arguments too,
> > see below).
> 
> Thanks for insulting me. (I do not really care but it is good when it
> goes against the users but it is bad when it is against DDs?)

I did not insult you. I just wrote that you make claims without
any arguments that do not match reality. In contrast, I demonstrated
that your claims are false and have shown how initramfs is a superior
solution compared a stand-alone root filesystem.

> 
> [systemd religiosity]
> > Just accept reality and move on.
> 
> That would mean to let debian die in its religious systemd world?

It has absolutely nothing to do with systemd.

> 
> > There is no reason to try to keep that separate / madness up anymore:
> > 
> > (1) we have better solutions now
> 
> Seems to be no.

I have given you one reasonable argument that we do have a better
solution with initramfs and proved that it solves all problems
that existed with a separate /usr partition.

> 
> > (2) nobody really uses the it -> no testing
> 
> I didn't know that my name is nobody. And I also didn't know that I
> share this name with many others.

Your name is not nobody. There might be a modest minority of users that
use a separate /usr without an initramfs. Standard Debian installations
use initramfs since a very long time.

And as so often, this stuff breaks. And if it is not used by the people
doing the uploads (and this is a huge group of people), the chance that
it will break installations without anyone noticing early is huge.

> It is just in your limited reality where it is "alternativlos", just to
> qoute chancellor Merkel.

eww.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Martin Pitt]

Hello Martin,

Martin Steigerwald [2016-11-30  9:20 +0100]:
> Also agreed to that… libsystemd is almost one third of the size of libc6.so 
> here… and it seems upstream basically stuffes *everything* into it, including 
> reading process attributes that IMHO would be a task for a *different* shared 
> object like the much lighter libprocps.so.6.0.0.
> 
> But the discussion would need to be brought upstream

Please let me clarify that you are talking about two different issues:

  1. libsystemd being too big, which is the part which can and should
  be discussed on the upstream systemd list indeed, as that's not
  something which is appropriate to change downstream. But this is
  entirely unrelated to this bug report.

  I sympathize with this, and maybe the earlier split into three
  smaller libraries was the better choice. And if someone refrains
  from starting the discussion with a tone like "you guys suck, break
  everything, and want to dominate the world", it might even be
  successful :-) (please forgive me the exaggeration)

  2. Debian supporting separate /usr without an initrd, and by
  extension, if boot-critical bits can link to stuff in /usr, which
  this bug is about. This is entirely a downstream Debian packaging
  issue (we could move liblz4 to /lib, like we did with other
  libraries), and does not belong on an upstream ML.

  Personally I think this part is a lost cause, both for technical
  reasons that have existed for a long time (which I will not repeat
  here), and even more so because the ongoing move to the /usr merge
  will make this completely obsolete -- if the *entire* OS is in /usr,
  then there is no alternative to an initrd anyway. This will finally
  make the whole design simpler, robust, maintainable, and reduce
  combinatorial explosion.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mi den 30. Nov 2016 um  9:36 schrieb Julian Andres Klode:
> In your imagination, that is (yes, I too can write stupid replies
> without any arguments - but I actually can provide arguments too,
> see below).

Thanks for insulting me. (I do not really care but it is good when it
goes against the users but it is bad when it is against DDs?)

[systemd religiosity]
> Just accept reality and move on.

That would mean to let debian die in its religious systemd world?

> There is no reason to try to keep that separate / madness up anymore:
> 
> (1) we have better solutions now

Seems to be no.

> (2) nobody really uses the it -> no testing

I didn't know that my name is nobody. And I also didn't know that I
share this name with many others.

It is just in your limited reality where it is "alternativlos", just to
qoute chancellor Merkel.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlg+kY0ACgkQpnwKsYAZ
9qzRxgv/Yv2pUPnreIkk/GrZ1nQ3x8dMLM1ASlWpov1lU0vacx2jMOqWho3Oyol9
oliRw/greuTuEHWhnjRYSSp6LvJjbrhK1zGxwOfo7m9PV9NKnsbkgsDsfpYwVgLD
yMNklpVaIa/l8X4/av+vGKIGcPovDhOGDzr5md3wvSNmddafEaiL+uK/BygTvDjk
wCNOX5mneRHR4ZNcjN7hqzJUTYZ8bYUJPTLl9/6abVfFg1jkzEwloR04znv0iPY+
Zl9oIvJo6Ov/T4kMdKkS8BkdMMS9E5jjH+LZ6BYaVyS2nwV6usc9KrfViDdxeEDn
xCa+PXQxyTEa5XUUc1b8lh+dj1V1u+HJUvj1rinr8Ig/SB+yaWFy5X1nfw/glF1c
k9SRWWW1bGEPQgQPt7sUhu/FLHz/w7synK8YvFZjZqx1ws2aXuB++z6d/bZFlsLE
+lAu6DeObAlmQx0h9eIVbR5i6KEppvJHT5Vzkoz4RX7FF81g8UUui1H0eXo/blia
RYV3enkz
=XJVt
-END PGP SIGNATURE-

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Julian Andres Klode]

(Huh, all emails are CCing listmaster - let's drop them for this
 subthread for now.)

On Wed, Nov 30, 2016 at 07:46:31AM +0100, Klaus Ethgen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi Martin,
> 
> Am Di den 29. Nov 2016 um 22:36 schrieb Martin Pitt:
> > Cristian Ionescu-Idbohrn [2016-11-29 22:16 +0100]:
> > > Eversince systemd came about into debian, you've shown direct or
> > > indirect disrespect, IMO, to people objecting against screwing up
> > > their systems, where they want to keep sysv instead of adopting
> > > systemd world domination.
> > 
> > The root issue here is not about the init system, but how initramfses
> > and separate partitions play together. Separate /usr without an initrd
> > has always been slightly broken,
> 
> No, it worked well for decades and it was exactly why you have small
> root and resizable /usr on other medias.

In your imagination, that is (yes, I too can write stupid replies
without any arguments - but I actually can provide arguments too,
see below).

> 
> It start getting broken when systemd start taking over the world.
> 
> > So, the set of what can be supported is certainly debatable, but as
> > history has shown it neither makes sense to support this use case nor
> > did anyone manage to actually do it. Hence the "wontfix".
> 
> As history shows, that is common use case and makes fully sense.

It used to make sense, but it never really worked, as you cannot make
a reasonable static decision as to what goes into / vs /usr. And thus,
some people had stuff like network they needed for mounting /usr or
otherwise early in boot, but the binaries for that happened to be in
/usr.

*All* these problems were solved with the introduction of initramfs,
which allows us to make the decision as to a minimal root filesystem
dynamically on the actual system.

Why maintain a second solution that is a lot of work, (because it)
always breaks, and only solves a small subset of the problems?

> 
> > Also, *if* you want to make this about systemd vs. SysV again:
> 
> Well, systemd, or better the religiosity, systemd is spread, is part of
> this particular problem. Exactly that is the case, why so many users
> oppose systemd.
> 
> However, this should be fight somewhere else. Here we have a real
> problem, that is easily fixable. Look at devuan or debian jessie. Just
> do not link against libsystemd what pulls in too many uncontrollable
> dependencies.

Just accept reality and move on.

There is no reason to try to keep that separate / madness up anymore:

(1) we have better solutions now
(2) nobody really uses the it -> no testing

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#845480: /bin/ps depends on /usr/lib/... which makes the system unbootable

[Martin Steigerwald]

Am Mittwoch, 30. November 2016, 07:46:31 CET schrieb Klaus Ethgen:
> > Also, *if* you want to make this about systemd vs. SysV again:
> Well, systemd, or better the religiosity, systemd is spread, is part of
> this particular problem. Exactly that is the case, why so many users
> oppose systemd.

I fully agree with that. As I pointed out before the fuss about systemd is not 
just technical, it is a social issue with the way upstream receives and reacts 
to any kind of feedback that criticizes the way systemd goes about things.

> However, this should be fight somewhere else. Here we have a real
> problem, that is easily fixable. Look at devuan or debian jessie. Just
> do not link against libsystemd what pulls in too many uncontrollable
> dependencies.

Also agreed to that… libsystemd is almost one third of the size of libc6.so 
here… and it seems upstream basically stuffes *everything* into it, including 
reading process attributes that IMHO would be a task for a *different* shared 
object like the much lighter libprocps.so.6.0.0.

But the discussion would need to be brought upstream, it just seems that these 
days no one dares to do that. I am not keen to subscribe to systemd-devel 
mailing list ever again after my last attempt to channel user feedback to this 
list and having been attacked with "now you are being a dick" by Lennart 
personally who on the other side rightfully complained about being attacked in 
person himself. (I unsubscribed from debian-devel mailing list back then for 
similar reasons.)

There is a split in the community that has never been healed, people just try 
to ignore it, but I doubt that this bug report would be the right place to go 
about this. And I wonder whether there is someone who would muster to bring up 
the courage to bring this up with upstream again in a constructive way.

Closing with a note to Michael: I learned to know you at DebConf 2016 and I 
value your work. However I didn´t see what you called an ad hominen attack as 
actually being one.

(I may refrain from any further comment here as I think its not really the 
place to discuss it.)

Thank you,
-- 
Martin

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers