Thanks for responding that quickly.
Am Fri, 3 May 2013 08:16:27 -0700
schrieb Steve Langasek :
> "upstream" means the bug is an upstream bug. Which is correct.
> > and why the debdiff patch is not being applied in debian?
>
> For the stated reason that I do not intend to apply this to the Deb
Hello,
I could not find the patch for this in the upstream bugtracker.
https://fedorahosted.org/linux-pam/query
Vorlon, you readded the upstream tag, I may be misundestanding
this, could you please clarify what you mean with the upstream status,
and why the debdiff patch is not being applied in
Tags: -upstream
Hello, please apply the patch for this blocking issue in debian.
Then reset this bug to upstream, after the patch actually is in debian
and has been submitted for inclusion upstream.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubs
Could you please push your fixes for wheezy?
This blocks 583971.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I see you fixed things in ubuntu, what ist the status for debian?
Did your patches get to, and accepted upstream?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
more systematically:
audio (access even if not at a console)
consolekit (may be granted access to devices if sitting at seat x)
consolekit-audio (access only to audio)
consolekit-shared (device access even if not alone at console)
consolekit-shared-audio (shared access only to audio)
--
To U
It may be preferable to keep the traditional meaning of the audio group
and use new ones for the consolekit behavior.
consolekit (may be granted access to devices if sitting at seat x)
audio (access even if not at a console)
consolekit-audio (access even if not alone at console)
-
Not sure if this is the way it works or it could work:
To deliver proper consolekit functionality even with audio group
members present:
If consolekit is installed and enabled, disable (udev?)
to set the ownership of sound devices to the audio group.
(policy: "give precedence to console users")
This belogs to gdm.
There is a patch to gdm applied in ubuntu as well as
in gdm's upstrem config examples
https://bugs.launchpad.net/debian/+source/gdm/+bug/393854
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..
Package: consolekit
Version: 0.4.1-4
On the general level:
Consolekit seems to switches permissions on devices,
but it does not support, actually conflicts, with the unix/debian way of
limiting the access to devices with user groups.
On the specific level:
Consolekit fails to switch permissions f
The continuous reboots also happen with regular PC partitions when the
first drive of a raid 1 fails and grub2 should boot from the second
drive.
http://debianforum.de/forum/viewtopic.php?f=13&t=127837
The workaround is to enable GRUB_TERMINAL=console
in /etc/default/grub
--
To UNSUBSCRIBE, e
Package: mdadm
As I see the redundancy of arrays is checked monthly (if the machine
happens to run in the early morning of the first sunday of the month).
This seems to happen as a background (kernel) process which only
logs to syslog. The checkarray command run by the cron job does not give
any
Hi, thanks for beeing so quick Santiago.
I guess that now makes #583958 "enable pam_umask usergroups by default"
an RC issue? Since we rely on it to set the umask.
Can someone adjust that?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe".
Example:
~$id
uid=1000(me) gid=1000(me)
groups=4(adm),20(dialout),24(cdrom),46(plugdev),108(lpadmin),1000(me)
We can tell that "me" is a private group of user "me"
because:
* me==me
* 1000==1000
* "getent group me" returns: "me:x:1000:"
(i.e. me is not listed explicitly like in "me:x:1000:me",
Am Mon, 31 May 2010 21:05:33 -0700
schrieb Steve Langasek :
> I don't understand this bug reprt. What are you asking to have
> changed in pam_umask?
>
pam_umask's "usergroups" functionality currently only checks if
username==groupname and GID==UID, before setting a relaxed umask.
If "usergroup
Package: libpam-runtime
Several unifying pam modules are not called from common-* files.
Instead they are only called from specific configs like pam.d/login.
Examples are pam_group and pam_environment.
(pam_group needs to be called before pam_umask)
This seems contrary to the notion of pam givin
Package: sudo
PAM modules like pam_umask, limits and pam_env don't work with sudo
because no common-session modules are included in sudo's pam config
file.
/etc/pam.d/sudo should be shipped containing the following line:
@include common-session-noninteracative
If "sudo -i" would really need it,
Package: adduser
(Filing this, to track the TODOs from the discussion that followed
http://lists.debian.org/debian-devel/2010/05/msg00887.html)
Am Wed, 26 May 2010 08:40:26 +0100
schrieb Stephen Gran :
> This one time, at band camp, Steve Langasek said:
> > On Tue, May 25, 2010 at 11:30:49PM +01
Package: login
(Filing this, to track the TODOs from the discussion that followed
http://lists.debian.org/debian-devel/2010/05/msg00887.html)
login.defs should contain UMASK 022 while pam_umask conditionally
relaxes it to 002 for private usergroups. (Like it used to
be before PAM was introduced,
Package: libpam-modules
(Filing this, to track the TODOs from the discussion that followed
http://lists.debian.org/debian-devel/2010/05/msg00887.html)
A private group is identifiable by username==groupname, UID==GID and:
> 2) A special case is true: The group is set as the main group of the
>
Package: base-files
(Filing this, to track the TODOs from the discussion that followed
http://lists.debian.org/debian-devel/2010/05/msg00887.html)
As soon as pam_umask is enabled by default and will set the umask on
all different types of logins to the system, the umask override in
/etc/profile s
Package: libpam-modules
(Filing this, to track the TODOs from the discussion that followed
http://lists.debian.org/debian-devel/2010/05/msg00887.html)
Enabling "pam_umask usergroups" (now that pam_umask is available) will
re-enable debian's user private group setup to work correctly.
There is a
By not adding the user (a second time) to its maingroup in /etc/groups,
adduser identifies the group as a user private group, and is able to
remove the group together with the user, if the group is not used
otherwise (standard case for debian UPGs).[0]
So "deluser does not remove empty main group
Hm, I'd say rather fix adduser to ensure GUI==UID.
Debian policy states: "Packages other than base-passwd must not
modify /etc/passwd, /etc/shadow, /etc/group
or /etc/gshadow." (http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2)
So fixing adduser or useradd? should be sufficient, can y
Hi, thanks for your message.
Am Mon, 17 May 2010 14:09:11 +0200 (CEST)
schrieb Santiago Vila :
> I would prefer this umask setting being handled by PAM, yes.
>
> What would be the steps for that?
As I don't have access to debian servers ATM, maybe you could quickly
check by "man pam_umask" if
Thank you for looking into and solving the default umask issue.
In the meantime (at least from following ubuntu) it seams the pam_umask
has long entered main and it gave us back /etc/login.defs as a central
place to set the umask (without depending on umask settings
in particular shell rc scripts
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 ge
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 f
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,
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/pa
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
Package: pmount
Version: 0.8-2
1) use umask determined mount options rather than hardcoded options
A filesystem can generally be mounted privately for a single user/group or
shared.
It should be a sane default to mount privately. I.e. this is with the system's
umask. (When detecting the umas
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 ca
Package: mount
Version: 2.12p-4sarge1
Severity: minor
The man page states:
nosuid Do not allow set-user-identifier or set-group-identifier
bits to take effect. (This seems safe, but is
in fact rather unsafe if you have suidperl(1) installed.
Hi Pierre,
I submitted the bug because handling some users with kuser did interfere in
with the regular tools on my system.
I figured it is because kmail does not use the mechanisms provided in debian
to alter conf files.
Fine if kuser will now delete private groups of users when they have on
35 matches
Mail list logo
