Bug#344030: status: Bug#344030: Profiles are not active upon logins like ssh -X

2017-09-22 Thread Holger Levsen
control: tags -1 + moreinfo

Hi,

what's the status of this bug?

Bug#344030: Profiles are not active upon logins like ssh -X

From reading the bug log as well as the debian/changelog for desktop-profiles 
1.4.9 and 1.4.11 it seems like the bug has been fixed, partly?

Is this still an issue given all the changes since 2006? :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature


Bug#344030: Profiles are not active upon logins like ssh -X

2006-02-12 Thread cobaco (aka Bart Cornelis)
I now a have a fix for psh users ready, will be in 1.4.11 

As psh is orphaned I'm planning to get an NMU ready with 
modularized /etc/pshrc, 1.4.11 will be uploaded once that's in
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpo3Ucg8fqmr.pgp
Description: PGP signature


Bug#344030: Profiles are not active upon logins like ssh -X

2006-02-02 Thread cobaco (aka Bart Cornelis)
This bug is mostly dealt with in 1.4.10:
- Shell specific fixes are documented for the following shells:
  - bash,dash, ksh, pdksh, mksh (i.e. the bourne-compatible shells)
  - csh and tcsh
  - zsh
  - fish
  - zoidberg
  See /usr/share/doc/desktop-profiles/README for details.
- The fix for fish is currently the only one that can be applied
  automatically, as fish is currently the only shell who'se system-wide
  on-logon script is modularized by this package. I'll be filing bugs
  requesting modularization for each of the others.
- rssh and sash don't require fixes (the former doesn't allow starting
  graphical clients, the latter is only intented for recovery situations)
- I don't yet have fixes documented for:
  - psh - should be similar to the zoidberg fix, but I haven't gotten it to
   work sofar (the sparse documentation doesn't help)
  - slsh - I'm completely unfamiliar with S-lang help would is welcome

The above should cover all shells in Debian, if anybody knows of any I 
missed let me know.
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpEOC5TVsfh6.pgp
Description: PGP signature


Bug#344030: Profiles are not active upon logins like ssh -X

2006-01-06 Thread cobaco (aka Bart Cornelis)
On Tuesday 03 January 2006 17:06, C. Gatzemeier wrote:
 Am Montag, 2. Januar 2006 15:17 schrieb cobaco (aka Bart Cornelis):
  I haven't been able to find a general solution for this. The only
  solution I see at the moment is to add a shell snippet to the
  system-wide on-login

 Hmm, when a pam-module can't source files in the name of a shell that is
 started only later, maybe the shell could be convinced to do so.

yep, that's what I was looking at. Current status is thus:
- I have the code to make this happen (at least for bourne-compatible
  shells) ready
- It will be included in package version 1.4.9 (which I just send to my
  sponsor for upload). 
  
  BUT that code isn't active by default because it needs to get added
  to /etc/profile which can't be done automatically at the moment (as that
  belongs to the base-files package).
  
  I'm stuck without a way to resolve that ATM as the base-files maintainer
  does not think it a good idea to add a mechanism to allow this, and he
  seems to feel that the default /etc/profile should be as simple and basic
  as possible, so getting the snippet added directly is out also.
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpmD4Mtva9T8.pgp
Description: PGP signature


Bug#344030: Profiles are not active upon logins like ssh -X

2006-01-06 Thread C. Gatzemeier
Am Samstag, 7. Januar 2006 01:40 schrieben Sie:
  I'm stuck without a way to resolve that ATM as the base-files maintainer
   does not think it a good idea to add a mechanism to allow this, and he
   seems to feel that the default /etc/profile should be as simple and basic
   as possible, so getting the snippet added directly is out also.

My thought was that maybe /etc/profile would not need to be changed nor 
base-files need to be modularized.

That is when a pam_module can pass a parameter to the shell that makes it 
source a different file than /etc/profile (or appropriate) and /etc/profile 
is then sourced from that file(s).



Bug#344030: Profiles are not active upon logins like ssh -X

2006-01-03 Thread C. Gatzemeier
Am Montag, 2. Januar 2006 15:17 schrieb cobaco (aka Bart Cornelis):
 On Monday 19 December 2005 15:55, C. Gatzemeier wrote:
  Profiles are not active upon logins like ssh -X since the
  desktop-profiles script is an xsession.d script.

 I haven't been able to find a general solution for this. The only solution
 I see at the moment is to add a shell snippet to the system-wide on-login

Hmm, when a pam-module can't source files in the name of a shell that is 
started only later, maybe the shell could be convinced to do so.

I am thinking of a parameter like --rcfile that shells take.

Or from man bash:

If arguments remain after option processing, and neither the -c nor the
-s  option  has  been supplied, the first argument is assumed to be the
name of a file containing shell commands.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#344030: Profiles are not active upon logins like ssh -X

2006-01-02 Thread cobaco (aka Bart Cornelis)
On Monday 19 December 2005 15:55, C. Gatzemeier wrote:
 Profiles are not active upon logins like ssh -X since the
 desktop-profiles script is an xsession.d script.

I haven't been able to find a general solution for this. The only solution I 
see at the moment is to add a shell snippet to the system-wide on-login 
script for each shell that sources the profile activation sript for an 'ssh 
-X logon.

The following snippet works for bourn-compatible shells when added 
to /etc/profile:
# testing SSH_CLIENT as the woody ssh doesn't set SSH_CONNECTION
# also testing SSH_CONNECTION as the current ssh manpage no longer mentions
# SSH_CLIENT, so it appears that variable is being phased out.
if ( ( (test -n ${SSH_CLIENT}) || (test -n ${SSH_CONNECTION}) )  \
 (test -n ${DISPLAY}) ); then
  source /etc/X11/Xsession.d/20desktop-profiles_activateDesktopProfiles
fi;

this gives the following todo:
- document the bug and proposed solution in desktop-profiles README
- file bugs with the respective shells to add an profile.d dir or similar,
  giving packages a policy-compliant way of adding shell snippets to the
  systemwide shell-logon script.
- wait for filed bugs to be fixed and add the necessary snippets when it
  becomes possible to do so.
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpVGhH1ibGIp.pgp
Description: PGP signature


Bug#344030: Profiles are not active upon logins like ssh -X

2005-12-22 Thread cobaco (aka Bart Cornelis)
On Wednesday 21 December 2005 15:32, Bart Cornelis wrote:
 On Monday 19 December 2005 15:55, C. Gatzemeier wrote:
  Profiles are not active upon logins like ssh -X since the
  desktop-profiles script is an xsession.d script.

 Looking at sshd(8) I see that there's /etc/ssh/sshrc to be used
 formachine-specific global login-time initializations.

 = at this point I'm thinking we should convince the ssh maintainers to
 add a mechanism similar to Xsession.d/ that could be used by
 desktop-profiles, gnupg-agent and similar packages.

tested that last night, that approach doesn't work as 
apperently /etc/ssh/sshrc is executed instead of sourced
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpieFs7HoR4s.pgp
Description: PGP signature


Bug#344030: Profiles are not active upon logins like ssh -X

2005-12-22 Thread C. Gatzemeier
Am Mittwoch, 21. Dezember 2005 16:45 schrieb cobaco (aka Bart Cornelis):

 sounds more like we need a small PAM-module that looks in something akin to
 Xsession.d for scripts to be sourced at login.

That would be nice, here is the source for such a module:
http://www.kernel.org/pub/linux/libs/pam/pre/modules/pam_preprofile.tgz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#344030: Profiles are not active upon logins like ssh -X

2005-12-22 Thread Bart Cornelis
On Thursday 22 December 2005 12:29, C. Gatzemeier wrote:
 Am Mittwoch, 21. Dezember 2005 16:45 schrieb cobaco (aka Bart Cornelis):
  sounds more like we need a small PAM-module that looks in something
  akin to Xsession.d for scripts to be sourced at login.

 That would be nice, here is the source for such a module:
 http://www.kernel.org/pub/linux/libs/pam/pre/modules/pam_preprofile.tgz

Took a quick look, seems this is not quite what we need:
- this allows to execute arbitrary scripts,
- we need to be able to set environment variables, so we need to be able to 
source scripts.
-- 
mvg, Bart Cornelis


pgpA1r9CRGeUT.pgp
Description: PGP signature


Bug#344030: Profiles are not active upon logins like ssh -X

2005-12-22 Thread C. Gatzemeier
Am Donnerstag, 22. Dezember 2005 13:26 schrieb Bart Cornelis:

  http://www.kernel.org/pub/linux/libs/pam/pre/modules/pam_preprofile.tgz

 Took a quick look, seems this is not quite what we need:
 - this allows to execute arbitrary scripts,
 - we need to be able to set environment variables, so we need to be able to
 source scripts.

Unfortunately pam_env, too, may not source any file. From the docs only, I 
think it only reads /etc/security/pam_env.conf and /etc/environment and sets 
the environment accordingly.

A reasonable workaround using only pam_env doesn't seem to be available at the 
moment either. At least the version in sarge does not seem to support any 
sort of user specific ~/.pam_env.conf file.

Seems this is as far as I could help with this. I don't know how to source 
something like run-parts (source-parts?) from pam_preprofile or to rewrite it 
to a more potent pam_profiles.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#344030: Profiles are not active upon logins like ssh -X

2005-12-21 Thread Bart Cornelis
On Monday 19 December 2005 15:55, C. Gatzemeier wrote:
 Profiles are not active upon logins like ssh -X since the
 desktop-profiles script is an xsession.d script.

 If desktop-profiles could be activated with a PAM module the behaviour
 could be the same regardless how the user entered the system.
 The problem came to my attention when a user starting kmail over ssh -X
 lost his settings aferwards. The loss of data is a bug in kmail, but it
 hinted to the missing profiles.

Note that a similar problem is activer for the gnupg-agent package whose 
Xsession.d-script also does some setup used by kmail (when using 
gpg-signing in any case), and possibly other packages adding Xsession.d 
scripts.

Note also that sshd_config(5) tels us that:
- sshd only uses PAM when UsePAM is set to yes
- that setting defaults to 'no'

= creating a PAM-module doesn't seam like a real solution

Looking at sshd(8) I see that there's /etc/ssh/sshrc to be used 
formachine-specific global login-time initializations.

= at this point I'm thinking we should convince the ssh maintainers to add 
a mechanism similar to Xsession.d/ that could be used by desktop-profiles, 
gnupg-agent and similar packages.
-- 
mvg, Bart Cornelise  


pgpJujVDaVcar.pgp
Description: PGP signature


Bug#344030: Profiles are not active upon logins like ssh -X

2005-12-21 Thread C. Gatzemeier
Am Mittwoch, 21. Dezember 2005 15:32 schrieb Bart Cornelis:

 Note also that sshd_config(5) tels us that:
 - sshd only uses PAM when UsePAM is set to yes
 - that setting defaults to 'no'

Correct, PAM systems, and debian in particular; have it set to yes though.

Another case where using PAM is part of the solution is the setting of the 
umask in debian. The default umask at the momentd needs to be changed in 
several places. In the future pam-umask will be part of base and be the 
central point for configuring the default umask.

I don't know though if desktop-profiles or gnupg-agent etc. would need a 
separate small PAM module like pam_umask or could be hooked into another?

Regards,
Christian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#344030: Profiles are not active upon logins like ssh -X

2005-12-21 Thread cobaco (aka Bart Cornelis)
On Wednesday 21 December 2005 16:02, C. Gatzemeier wrote:
 Am Mittwoch, 21. Dezember 2005 15:32 schrieb Bart Cornelis:
  Note also that sshd_config(5) tels us that:
  - sshd only uses PAM when UsePAM is set to yes
  - that setting defaults to 'no'

 Correct, PAM systems, and debian in particular; have it set to yes
 though.

 Another case where using PAM is part of the solution is the setting of
 the umask in debian. The default umask at the momentd needs to be changed
 in several places. In the future pam-umask will be part of base and be
 the central point for configuring the default umask.

 I don't know though if desktop-profiles gnupg-agent etc. would need a
 separate small PAM module like pam_umask or could be hooked into another?

sounds more like we need a small PAM-module that looks in something akin to 
Xsession.d for scripts to be sourced at login.
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpyU5ypz7f1K.pgp
Description: PGP signature


Bug#344030: Profiles are not active upon logins like ssh -X

2005-12-19 Thread C. Gatzemeier
Package: desktop-profiles
Version: 1.4.8


Profiles are not active upon logins like ssh -X since the
desktop-profiles script is an xsession.d script.

If desktop-profiles could be activated with a PAM module the behaviour
could be the same regardless how the user entered the system.

The problem came to my attention when a user starting kmail over ssh -X
lost his settings aferwards. The loss of data is a bug in kmail, but it
hinted to the missing profiles.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]