Re: [PATCH] printk loglevel cleanup (again)

Re: [PATCH] printk loglevel cleanup (again)

[Pete Zaitcev]

Linus refused wholesale cleanups in the past. Try to identify
worst offenders and start from those, and work through component
maintainers. It's a lot more work, but you have to tough it out.

-- Pete

> When I was making this patch I couldn't resist and fixed
> messed up tabs around affected printks, wrapped some
> lines longer than 80 columns, fixed some typos.

[PATCH] printk loglevel cleanup (again)

[vda]

Since we are past 2.5.0 point, I hope this patch have better chances,
at least for 2.5.x :-)

Primary purpose of this patch is to make KERN_WARNING and
KERN_INFO log levels closer to their original meaning.
Today they are quite far from what was intended.
Just look what kernel writes at the WARNING level
each time you boot your box!

When I was making this patch I couldn't resist and fixed
messed up tabs around affected printks, wrapped some
lines longer than 80 columns, fixed some typos.
My formatting preferences:
* log entries are started with capital letters except for
function/modules names in lowercase or acronyms (IDE etc)
* Dot before \n is a waste of space
* colon style: "Foo: blah blan" (not "Foo : blah" or "Foo: Blah")
But I'm not a religious fanatic: it ok to disagree with me :-)
You can see in the patch that I wasn't overly distracted
by this decorative work.

I'm doing my best trying not to break working code.
However, if you feel paranoid today you may remove
any hunk of this patch you may deem suspicious
and apply the rest - all these changes are independent
of each other, you may even just ignore rejects
if you are patching newer/older kernel!

If you like this patch but have more interesting things to play with,
you may do the following:
* clear your logs
* reconfigure syslogd to spew warnings to /var/log/syslog.warnings
* reboot
* mail boot time "warnings" which you think are not warnings but
info only ("104-key keyboard detected"-type msgs) to me -
I'll add fixes for those to this patch

Go to: http://port.imtp.ilyichevsk.odessa.ua/linux/vda/
--
vda

Small security bug with misconfigured access rights

[Giuliano Pochini]

Well, I don't know if it is really a bug.

Create a directory like this:

# ls -la
total 12
drwxr-sr-x   2 pochini  root         4096 Nov 28 16:33 .
drwxr-xr-x  32 pochini  users        8192 Nov 28 16:25 ..

Sgid bit is set and the directory is owned by me and the
group is root (yes, it shouldn't be).

When I create a file here, it gets the root group even
if I don't belong to it.

[kernel 2.4.5]


Bye.

Re: [PATCH] printk loglevel cleanup (again)

[vda]

On Tuesday 27 November 2001 15:58, Pete Zaitcev wrote:
> Linus refused wholesale cleanups in the past. Try to identify
> worst offenders and start from those, and work through component
> maintainers. It's a lot more work, but you have to tough it out.

This patch can be split into individual patches right at any hunk boundary.
I think any interested maintainer can take it and apply relevant parts (or as 
a whole, since their diffs for Linus are most probaly made only from relevant 
kernel subtrees (they won't propagate unwanted modifications))

Anyway, it's only printks.
--
vda

Re: Small security bug with misconfigured access rights

[Jordan Russell]

Giuliano Pochini wrote:
> Well, I don't know if it is really a bug.
>
> Create a directory like this:
>
> # ls -la
> total 12
> drwxr-sr-x   2 pochini  root         4096 Nov 28 16:33 .
> drwxr-xr-x  32 pochini  users        8192 Nov 28 16:25 ..
>
> Sgid bit is set and the directory is owned by me and the
> group is root (yes, it shouldn't be).
>
> When I create a file here, it gets the root group even
> if I don't belong to it.

That's the correct behavior. Quoting "man mount":

       grpid or bsdgroups / nogrpid or sysvgroups
              These options define what group id a newly  created  file
gets.   When
              grpid  is  set,  it  takes the group id of the directory in
which it is
              created; otherwise (the default) it takes the fsgid of the
current pro-
              cess,  unless  the  directory  has the setgid bit set, in
which case it
              takes the gid from the parent directory, and also gets the
setgid  bit
              set if it is a directory itself.


Jordan Russell