things to be done after cvs->git migration
by Dmitry V. Levin
Based on my experience of earlier cvs->git migrations, there are few
things that could be done naturally now:
- migrate from .cvsignore to .gitignore;
- cleanup trailing whitespaces and indentation that uses spaces before
tabs as reported by
git diff --check 4b825dc642cb6eb9a060e54bf8d69288fbee4904 HEAD
- adjust hooks/update to reject new commits introducing new trailing
whitespaces;
- accept a guideline about git commit messages style and maintaining
ChangeLog file in git; I propose to deprecate the ChangeLog file in
the repository, follow to commit log requirements (e.g. based on
"Commit log requirements" described in
http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING), and
use the gitlog-to-changelog tool to generate the ChangeLog file from
git log at "make dist" time.
I made these changes in strace project after cvs->git migration in
July of 2009, and everybody seems to be happy so far.
--
ldv
12 years, 5 months
[PATCH] pam_limits: initialize rlimits from kernel values
by Kees Cook
Since the kernel sets a number of dynamic rlimits based on the system
properties (e.g. physical memory for nproc), these rlimits should be
respected by PAM. Parse /proc/1/limits for the kernel-defined rlimits.
Signed-off-by: Kees Cook <kees.cook(a)canonical.com>
---
modules/pam_limits/pam_limits.c | 157 +++++++++++++++++++++++++++++++++++++-
1 files changed, 152 insertions(+), 5 deletions(-)
diff --git a/modules/pam_limits/pam_limits.c b/modules/pam_limits/pam_limits.c
index 8814652..fa1d35f 100644
--- a/modules/pam_limits/pam_limits.c
+++ b/modules/pam_limits/pam_limits.c
@@ -51,9 +51,10 @@
#define LIMITS_DEF_USER 0 /* limit was set by an user entry */
#define LIMITS_DEF_GROUP 1 /* limit was set by a group entry */
#define LIMITS_DEF_ALLGROUP 2 /* limit was set by a group entry */
-#define LIMITS_DEF_ALL 3 /* limit was set by an default entry */
-#define LIMITS_DEF_DEFAULT 4 /* limit was set by an default entry */
-#define LIMITS_DEF_NONE 5 /* this limit was not set yet */
+#define LIMITS_DEF_ALL 3 /* limit was set by an all entry */
+#define LIMITS_DEF_DEFAULT 4 /* limit was set by a default entry */
+#define LIMITS_DEF_KERNEL 5 /* limit was set from /proc/1/limits */
+#define LIMITS_DEF_NONE 6 /* this limit was not set yet */
#define LIMIT_RANGE_ERR -1 /* error in specified uid/gid range */
#define LIMIT_RANGE_NONE 0 /* no range specified */
@@ -67,6 +68,7 @@ static const char *limits_def_names[] = {
"ALLGROUP",
"ALL",
"DEFAULT",
+ "KERNEL",
"NONE",
NULL
};
@@ -292,7 +294,139 @@ check_logins (pam_handle_t *pamh, const char *name, int limit, int ctrl,
return 0;
}
-static int init_limits(struct pam_limit_s *pl)
+static const char * lnames[RLIM_NLIMITS] = {
+ [RLIMIT_CPU] = "Max cpu time",
+ [RLIMIT_FSIZE] = "Max file size",
+ [RLIMIT_DATA] = "Max data size",
+ [RLIMIT_STACK] = "Max stack size",
+ [RLIMIT_CORE] = "Max core file size",
+ [RLIMIT_RSS] = "Max resident set",
+ [RLIMIT_NPROC] = "Max processes",
+ [RLIMIT_NOFILE] = "Max open files",
+ [RLIMIT_MEMLOCK] = "Max locked memory",
+#ifdef RLIMIT_AS
+ [RLIMIT_AS] = "Max address space",
+#endif
+#ifdef RLIMIT_LOCKS
+ [RLIMIT_LOCKS] = "Max file locks",
+#endif
+#ifdef RLIMIT_SIGPENDING
+ [RLIMIT_SIGPENDING] = "Max pending signals",
+#endif
+#ifdef RLIMIT_MSGQUEUE
+ [RLIMIT_MSGQUEUE] = "Max msgqueue size",
+#endif
+#ifdef RLIMIT_NICE
+ [RLIMIT_NICE] = "Max nice priority",
+#endif
+#ifdef RLIMIT_RTPRIO
+ [RLIMIT_RTPRIO] = "Max realtime priority",
+#endif
+#ifdef RLIMIT_RTTIME
+ [RLIMIT_RTTIME] = "Max realtime timeout",
+#endif
+};
+
+static int str2rlimit(char *name) {
+ int i;
+ if (!name || *name == '\0')
+ return -1;
+ for(i = 0; i < RLIM_NLIMITS; i++) {
+ if (strcmp(name, lnames[i]) == 0) return i;
+ }
+ return -1;
+}
+
+static rlim_t str2rlim_t(char *value) {
+ unsigned long long rlimit = 0;
+
+ if (!value) return (rlim_t)rlimit;
+ if (strcmp(value, "unlimited") == 0) {
+ return RLIM_INFINITY;
+ }
+ rlimit = strtoull(value, NULL, 10);
+ return (rlim_t)rlimit;
+}
+
+#define LIMITS_SKIP_WHITESPACE { \
+ /* step backwards over spaces */ \
+ pos--; \
+ while (pos && line[pos] == ' ') pos--; \
+ if (!pos) continue; \
+ line[pos+1] = '\0'; \
+}
+#define LIMITS_MARK_ITEM(item) { \
+ /* step backwards over non-spaces */ \
+ pos--; \
+ while (pos && line[pos] != ' ') pos--; \
+ if (!pos) continue; \
+ item = line + pos + 1; \
+}
+
+static void parse_kernel_limits(pam_handle_t *pamh, struct pam_limit_s *pl)
+{
+ int i, maxlen = 0;
+ FILE *limitsfile;
+ const char *proclimits = "/proc/1/limits";
+ char line[256];
+ char *units, *hard, *soft, *name;
+
+ if (!(limitsfile = fopen(proclimits, "r"))) {
+ pam_syslog(pamh, LOG_WARNING, "Could not read %s (%s), using PAM defaults", proclimits, strerror(errno));
+ return;
+ }
+
+ while (fgets(line, 256, limitsfile)) {
+ int pos = strlen(line);
+ if (pos < 2) continue;
+
+ /* drop trailing newline */
+ if (line[pos-1] == '\n') {
+ pos--;
+ line[pos] = '\0';
+ }
+
+ /* determine formatting boundry of limits report */
+ if (!maxlen && strncmp(line, "Limit", 5) == 0) {
+ maxlen = pos;
+ continue;
+ }
+
+ if (pos == maxlen) {
+ /* step backwards over "Units" name */
+ LIMITS_SKIP_WHITESPACE;
+ LIMITS_MARK_ITEM(units);
+ }
+ else {
+ units = "";
+ }
+
+ /* step backwards over "Hard Limit" value */
+ LIMITS_SKIP_WHITESPACE;
+ LIMITS_MARK_ITEM(hard);
+
+ /* step backwards over "Soft Limit" value */
+ LIMITS_SKIP_WHITESPACE;
+ LIMITS_MARK_ITEM(soft);
+
+ /* step backwards over name of limit */
+ LIMITS_SKIP_WHITESPACE;
+ name = line;
+
+ i = str2rlimit(name);
+ if (i < 0 || i >= RLIM_NLIMITS) {
+ pam_syslog(pamh, LOG_DEBUG, "Unknown kernel rlimit '%s' ignored", name);
+ continue;
+ }
+ pl->limits[i].limit.rlim_cur = str2rlim_t(soft);
+ pl->limits[i].limit.rlim_max = str2rlim_t(hard);
+ pl->limits[i].src_soft = LIMITS_DEF_KERNEL;
+ pl->limits[i].src_hard = LIMITS_DEF_KERNEL;
+ }
+ fclose(limitsfile);
+}
+
+static int init_limits(pam_handle_t *pamh, struct pam_limit_s *pl)
{
int i;
int retval = PAM_SUCCESS;
@@ -313,6 +447,19 @@ static int init_limits(struct pam_limit_s *pl)
}
}
+#ifdef __linux__
+ parse_kernel_limits(pamh, pl);
+#endif
+
+ for(i = 0; i < RLIM_NLIMITS; i++) {
+ if (pl->limits[i].supported &&
+ (pl->limits[i].src_soft == LIMITS_DEF_NONE ||
+ pl->limits[i].src_hard == LIMITS_DEF_NONE)) {
+#ifdef __linux__
+ pam_syslog(pamh, LOG_WARNING, "Did not find kernel RLIMIT for %s, using PAM default", rlimit2str(i));
+#endif
+ }
+
errno = 0;
pl->priority = getpriority (PRIO_PROCESS, 0);
if (pl->priority == -1 && errno != 0)
@@ -873,7 +1020,7 @@ pam_sm_open_session (pam_handle_t *pamh, int flags UNUSED,
return PAM_USER_UNKNOWN;
}
- retval = init_limits(pl);
+ retval = init_limits(pamh, pl);
if (retval != PAM_SUCCESS) {
pam_syslog(pamh, LOG_WARNING, "cannot initialize");
return PAM_ABORT;
--
1.7.4.1
--
Kees Cook
Ubuntu Security Team
12 years, 10 months
hooks/post-receive needs to be adjusted
by Dmitry V. Levin
On Mon, Mar 21, 2011 at 09:05:12PM +0000, Tomáš Mráz wrote:
> commit 7698a76cf4983fe69944a810305183f1fe6cc031
[...]
I'd prefer if the hooks/post-receive hook would include ref names to
Subjects, and set appropriate Reply-To, which mailman should be instructed
not to override. How can I adjust that?
--
ldv
13 years, 1 month
hooks/post-receive hook needs to be fixed
by Dmitry V. Levin
On Mon, Mar 21, 2011 at 11:50:33PM +0300, Dmitry V. Levin wrote:
> Pushed to http://git.fedorahosted.org/git/?p=linux-pam.git;a=summary
>
> $ git push --all
> Counting objects: 12793, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (2294/2294), done.
> Writing objects: 100% (12793/12793), 3.28 MiB | 843 KiB/s, done.
> Total 12793 (delta 10348), reused 12793 (delta 10348)
> remote: Traceback (most recent call last):
> remote: File "hooks/post-receive", line 923, in ?
> remote: main()
> remote: File "hooks/post-receive", line 918, in main
> remote: change.prepare()
> remote: File "hooks/post-receive", line 229, in prepare
> remote: detailed_commit_args.append("^" + all_changes[branch].oldrev)
> remote: TypeError: cannot concatenate 'str' and 'NoneType' objects
This is a bug in hooks/post-receive, it shouldn't dump its internal noise
to users.
--
ldv
13 years, 1 month
Re: [Pam-developers] [Pam-patches] Move to Fedorahosted
by Tomas Mraz
On Mon, 2011-03-21 at 15:12 -0700, Steve Langasek wrote:
> On Tue, Mar 22, 2011 at 12:58:22AM +0300, Dmitry V. Levin wrote:
> > On Mon, Mar 21, 2011 at 02:36:46PM -0700, Steve Langasek wrote:
> > > On Mon, Mar 21, 2011 at 10:16:18PM +0100, Tomas Mraz wrote:
> > > > So the mailing lists (pam-developers(a)lists.fedorahosted.org and
> > > > linux-pam-commits(a)lists.fedorahosted.org) are created.
>
> > > > The git repository is working fine and Dmitry pushed the conversion of
> > > > the CVS repository into it.
>
> > > > I've committed a small fix there to test whether the commit mailing list
> > > > receives the commit messages from git on pushes - and it does.
>
> > > > I'd like to ask everyone watching this list to subscribe to
> > > > pam-developers(a)lists.fedorahosted.org - especially we did not hear
> > > > anything from Steve Langasek for a while.
>
> > > Do you have a link for the subscription interface for this list?
>
> > https://fedorahosted.org/linux-pam/ points to
> > https://fedorahosted.org/mailman/listinfo/pam-developers
>
> Thanks (also, I worked this out from the bounce message I got saying that my
> mail had been moderated :)
>
> What are the intended subscription/posting guidelines for this list? Is it
> meant to be only for those with commit access to the repository? I have a
> comaintainer of PAM packages in Debian and Ubuntu who I would like to be
> able to get more involved in PAM upstream, which is more difficult if the
> principal discussion among upstream developers all takes place on a closed
> list.
I think its purpose should be for discussions about Linux PAM project
development. It should not be closed for non upstream developers but
subscription should be required for posting. Of course the list is not
supposed to be used for discussions about user issues with PAM or 3rd
party software development. We are keeping pam-list(a)redhat.com for this
purpose.
We do not have a list for 0-day embargoed issues but I think mailing
directly to our individual e-mail addresses should be sufficient for
this purpose.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
13 years, 1 month
Re: [Pam-developers] [Pam-patches] Move to Fedorahosted
by Tomas Mraz
On Mon, 2011-03-21 at 14:36 -0700, Steve Langasek wrote:
> On Mon, Mar 21, 2011 at 10:16:18PM +0100, Tomas Mraz wrote:
> > So the mailing lists (pam-developers(a)lists.fedorahosted.org and
> > linux-pam-commits(a)lists.fedorahosted.org) are created.
>
> > The git repository is working fine and Dmitry pushed the conversion of
> > the CVS repository into it.
>
> > I've committed a small fix there to test whether the commit mailing list
> > receives the commit messages from git on pushes - and it does.
>
> > I'd like to ask everyone watching this list to subscribe to
> > pam-developers(a)lists.fedorahosted.org - especially we did not hear
> > anything from Steve Langasek for a while.
>
> Do you have a link for the subscription interface for this list?
Yes, I've added it to the linux-pam homepage on Fedora hosted.
https://fedorahosted.org/linux-pam/
And direct links to the mailing lists:
https://fedorahosted.org/mailman/listinfo/pam-developers
https://fedorahosted.org/mailman/listinfo/linux-pam-commits
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
13 years, 1 month
Move to Fedorahosted
by Tomas Mraz
So the mailing lists (pam-developers(a)lists.fedorahosted.org and
linux-pam-commits(a)lists.fedorahosted.org) are created.
The git repository is working fine and Dmitry pushed the conversion of
the CVS repository into it.
I've committed a small fix there to test whether the commit mailing list
receives the commit messages from git on pushes - and it does.
I'd like to ask everyone watching this list to subscribe to
pam-developers(a)lists.fedorahosted.org - especially we did not hear
anything from Steve Langasek for a while.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
13 years, 1 month