I wasn't sure where to send this but here goes.
Seems that many of the source files in the linux-2.6.14.tar.bz2 have
global read/write permissions.
Are the permissions supposed to be this way now?
If not, could this be fixed soon?
if so, could you point me to a url that explains why.
- David Brown
The rights on the files should be sufficient for the compiler to go through
the tree and compile the kernel for you. If it bothers you, you can just run
chmod -R to correct it.
I guess that it will not be corrected.
On Saturday 26 November 2005 22:58, you wrote:
> I wasn't sure where to send this but here goes.
>
> Seems that many of the source files in the linux-2.6.14.tar.bz2 have
> global read/write permissions.
> Are the permissions supposed to be this way now?
> If not, could this be fixed soon?
> if so, could you point me to a url that explains why.
>
> - David Brown
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
________
http://www.hipersonik.com : Open source experts
> The rights on the files should be sufficient for the compiler to go through
> the tree and compile the kernel for you. If it bothers you, you can just run
> chmod -R to correct it.
Yeah but it took me a couple of weeks and a few updates of my kernel
to find it...
Some one could have broke in and changed things without being root and
I wouldn't have noticed it.
> I guess that it will not be corrected.
I just find it odd that I now have to check permissions all over the
place to make sure everything is safe.
- David Brown
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Saturday 26 November 2005 23:27, David Brown wrote:
> > The rights on the files should be sufficient for the
> > compiler to go through the tree and compile the kernel
> > for you. If it bothers you, you can just run chmod -R
> > to correct it.
>
> Yeah but it took me a couple of weeks and a few updates
> of my kernel to find it...
> Some one could have broke in and changed things without
> being root and I wouldn't have noticed it.
>
> > I guess that it will not be corrected.
>
> I just find it odd that I now have to check permissions
> all over the place to make sure everything is safe.
>
Check your umask and set it to 022 ;)
> Check your umask and set it to 022 ;)
it is, still comes up world read/write.
- David Brown
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Saturday 26 November 2005 23:41, David Brown wrote:
> > Check your umask and set it to 022 ;)
>
> it is, still comes up world read/write.
Sorry for my sleepy advise.
sudo umask 022
sudo tar jxf linux-2.6.14.1.tar.bz2 --no-same-permissions
ls -l linux-2.6.14.1
-rw-r--r-- 1 root root 18693 Nov 8 20:22 COPYING
-rw-r--r-- 1 root root 89223 Nov 8 20:22 CREDITS
drwxr-xr-x 53 root root 5208 Nov 8 20:22 Documentation
-rw-r--r-- 1 root root 1258 Nov 8 20:22 Kbuild
-rw-r--r-- 1 root root 60997 Nov 8 20:22 MAINTAINERS
-rw-r--r-- 1 root root 43534 Nov 8 20:22 Makefile
-rw-r--r-- 1 root root 14755 Nov 8 20:22 README
-rw-r--r-- 1 root root 3065 Nov 8 20:22 REPORTING-BUGS
drwxr-xr-x 26 root root 632 Nov 8 20:22 arch
drwxr-xr-x 2 root root 968 Nov 8 20:22 crypto
drwxr-xr-x 22 root root 600 Nov 26 23:50 drivers
[snip]
>
> - David Brown
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to
> [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html Please read
> the FAQ at http://www.tux.org/lkml/
> Sorry for my sleepy advise.
>
> sudo umask 022
> sudo tar jxf linux-2.6.14.1.tar.bz2 --no-same-permissions
> ls -l linux-2.6.14.1
>
> -rw-r--r-- 1 root root 18693 Nov 8 20:22 COPYING
> -rw-r--r-- 1 root root 89223 Nov 8 20:22 CREDITS
> drwxr-xr-x 53 root root 5208 Nov 8 20:22 Documentation
> -rw-r--r-- 1 root root 1258 Nov 8 20:22 Kbuild
> -rw-r--r-- 1 root root 60997 Nov 8 20:22 MAINTAINERS
> -rw-r--r-- 1 root root 43534 Nov 8 20:22 Makefile
> -rw-r--r-- 1 root root 14755 Nov 8 20:22 README
> -rw-r--r-- 1 root root 3065 Nov 8 20:22 REPORTING-BUGS
> drwxr-xr-x 26 root root 632 Nov 8 20:22 arch
> drwxr-xr-x 2 root root 968 Nov 8 20:22 crypto
> drwxr-xr-x 22 root root 600 Nov 26 23:50 drivers
> [snip]
Aha, that option isn't in man page for tar but it is in the info page
for it... odd
Thanks, but I'd still like to know why the tarball isn't goinb to be
fixed on the main site.
- David Brown
On 11/26/05, David Brown <[email protected]> wrote:
> > Check your umask and set it to 022 ;)
>
> it is, still comes up world read/write.
Does using --no-same-permissions help when untarring?
Thanks,
Nish
> Does using --no-same-permissions help when untarring?
yeah that worked.
- David Brown
On Saturday 26 November 2005 21:58, David Brown wrote:
> I wasn't sure where to send this but here goes.
>
> Seems that many of the source files in the linux-2.6.14.tar.bz2 have
> global read/write permissions.
> Are the permissions supposed to be this way now?
> If not, could this be fixed soon?
> if so, could you point me to a url that explains why.
David, it'd probably help if you listed all of the affected files, then people
can explain themselves and/or correct the permissions.
I personally think that your point is valid and security should be considered
when packing the kernel sources. It might even be possible for Linus's
tarball script to remove global write permissions.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Sunday 27 November 2005 01:13, David Brown wrote:
> > David, it'd probably help if you listed all of the affected files, then
> > people can explain themselves and/or correct the permissions.
> >
> > I personally think that your point is valid and security should be
> > considered when packing the kernel sources. It might even be possible for
> > Linus's tarball script to remove global write permissions.
>
> Okay but it's kinda big here's how I did it.
>
> # for file in `find *` ; do if ls -l $file | grep -q '^.....w..w.' ;
> then ls -d $file ; fi ; done | wc -l
> 19552
> # find * | wc -l
> 19552
>
> seems to be all of them :\
>
> I'll attach the file list
Sure enough, I can confirm this.
I don't seem to have to provide --no-same-permissions to tar to get umask to
affect the permissions of extracted files, so my files are fine on-disc.
What disturbs me more is the number of people using insecure umasks before
checking files in! When does a text file really want to be a+w?
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On 11/26/05, Alistair John Strachan <[email protected]> wrote:
> On Sunday 27 November 2005 01:13, David Brown wrote:
> > > David, it'd probably help if you listed all of the affected files, then
> > > people can explain themselves and/or correct the permissions.
> > >
> > > I personally think that your point is valid and security should be
> > > considered when packing the kernel sources. It might even be possible for
> > > Linus's tarball script to remove global write permissions.
> >
> > Okay but it's kinda big here's how I did it.
> >
> > # for file in `find *` ; do if ls -l $file | grep -q '^.....w..w.' ;
> > then ls -d $file ; fi ; done | wc -l
> > 19552
> > # find * | wc -l
> > 19552
> >
> > seems to be all of them :\
> >
> > I'll attach the file list
>
> Sure enough, I can confirm this.
>
> I don't seem to have to provide --no-same-permissions to tar to get umask to
> affect the permissions of extracted files, so my files are fine on-disc.
FWIW, ubuntu's man-pages claim:
" --no-same-permissions
apply umask to extracted files (the default for non-root users)"
and
" -p, --same-permissions, --preserve-permissions
ignore umask when extracting files (the default for root)"
Maybe you are untarring as non-root and David is untarring as root?
> What disturbs me more is the number of people using insecure umasks before
> checking files in! When does a text file really want to be a+w?
That I do not know.
Thanks,
Nish
> Sure enough, I can confirm this.
>
> I don't seem to have to provide --no-same-permissions to tar to get umask to
> affect the permissions of extracted files, so my files are fine on-disc.
yeah it's a pretty easy fix on the system and it's a pretty easy fix
for the mirror, just needs to happen.
> What disturbs me more is the number of people using insecure umasks before
> checking files in! When does a text file really want to be a+w?
agreed many people compile and install their own kernels without using
their distros package manager to do it, I've sent emails to my distro
about the permissions problem with that tarball.
- David Brown
On Sunday 27 November 2005 01:46, Nish Aravamudan wrote:
[snip]
> >
> > Sure enough, I can confirm this.
> >
> > I don't seem to have to provide --no-same-permissions to tar to get umask
> > to affect the permissions of extracted files, so my files are fine
> > on-disc.
>
> FWIW, ubuntu's man-pages claim:
>
> " --no-same-permissions
> apply umask to extracted files (the default for non-root
> users)"
>
> and
>
> " -p, --same-permissions, --preserve-permissions
> ignore umask when extracting files (the default for root)"
>
> Maybe you are untarring as non-root and David is untarring as root?
>
Thanks Nish, this is obviously the difference. I never compile anything as
root (pesky Makefiles rm -rf'ing things!).
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
> Maybe you are untarring as non-root and David is untarring as root?
Yeah you can't very well compile and install a kernel without
permissions to /boot ;)
- David Brown
> Thanks Nish, this is obviously the difference. I never compile anything as
> root (pesky Makefiles rm -rf'ing things!).
Yeah, but you still need to install stuff as root... unless you do
weird stuff like installwatch or something.
- David Brown
On 11/26/05, David Brown <[email protected]> wrote:
> > Thanks Nish, this is obviously the difference. I never compile anything as
> > root (pesky Makefiles rm -rf'ing things!).
>
> Yeah, but you still need to install stuff as root... unless you do
> weird stuff like installwatch or something.
Uh, untarring is the operation that needs to be non-root. So just have
a build user or some other non-root user do the untarring and building
(which is recommended by most anyways, IIRC). Then, as root (or via
sudo) make modules_install install.
On 11/26/05, David Brown <[email protected]> wrote:
> Yeah you can't very well compile and install a kernel without
> permissions to /boot ;)
Again, you pretty clearly can *compile* a kernel as boot. root is only
needed for install (and this is the division of tasks that I use and
recommend to others).
Thanks,
Nish
> Uh, untarring is the operation that needs to be non-root. So just have
> a build user or some other non-root user do the untarring and building
> (which is recommended by most anyways, IIRC). Then, as root (or via
> sudo) make modules_install install.
This isn't an excuse to have unsecure permissions when extracting as
root though.
- David Brown
On Sat, Nov 26, 2005 at 11:53:23PM +0100, Michael Frank wrote:
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> On Saturday 26 November 2005 23:41, David Brown wrote:
> > > Check your umask and set it to 022 ;)
> >
> > it is, still comes up world read/write.
>
> Sorry for my sleepy advise.
>
> sudo umask 022
^^^^^^^^^^^^^^^
This one is not going to be useful, because it will only set the umask
for the shell launched by sudo.
> sudo tar jxf linux-2.6.14.1.tar.bz2 --no-same-permissions
Regards,
Willy
On Sat, Nov 26, 2005 at 05:51:34PM -0800, David Brown wrote:
> > Maybe you are untarring as non-root and David is untarring as root?
>
> Yeah you can't very well compile and install a kernel without
> permissions to /boot ;)
I disagree with you David. It's been years since I last compiled a
kernel as root, and even longer without untarring it as root ! I have
/usr/src chmod g+w for group "linux" to which I belong. I untar new
kernels there, compile them, etc... as my own user. Then I only do:
$ sudo make modules_install
$ sudo cp arch/i386/boot/bzImage System.map .config /boot/<version>
$ sudo vi /etc/lilo.conf
$ sudo lilo
And it brings me real advantages : during all the compilation phase,
I can use everything I have in *my* environment, aliases, functions,
scripts, tools, etc... that I would not necessarily have as root.
Believe me, for no reason I would switch back to the old age when
I did all this as root !
Regards,
Willy
On Sat, Nov 26, 2005 at 06:38:22PM -0800, David Brown wrote:
> > Uh, untarring is the operation that needs to be non-root. So just have
> > a build user or some other non-root user do the untarring and building
> > (which is recommended by most anyways, IIRC). Then, as root (or via
> > sudo) make modules_install install.
>
> This isn't an excuse to have unsecure permissions when extracting as
> root though.
It certainly is not an excuse, but at least it my explain why nobody
noticed it before you :-)
Regards,
Willy
>Aha, that option isn't in man page for tar but it is in the info page
>for it... odd
GNU does not officially create/use manpages.
I think it's the well known linux-manpages project that maintains them.
>Thanks, but I'd still like to know why the tarball isn't goinb to be
>fixed on the main site.
A hint, if --no-same-permission is too much to type, you may abbreviate it
with --no-same-p
Jan Engelhardt
--
> It certainly is not an excuse, but at least it my explain why nobody
> noticed it before you :-)
Thanks for the info and suggestions ;)
I trust Linus enough to compile a kernel as root... but maybe that's just me ;)
(or maybe I trust that I can fix anything that can fsck up my system
even with root perms ;))
I agree compiling the kernel as a non-root user is perfered but
sometimes it doesn't happen that way...
- David Brown
On Sun, Nov 27, 2005 at 01:22:26AM -0800, David Brown wrote:
> > It certainly is not an excuse, but at least it my explain why nobody
> > noticed it before you :-)
>
> Thanks for the info and suggestions ;)
> I trust Linus enough to compile a kernel as root... but maybe that's just me ;)
I don't, he's subject to errors just like any of us mere humans. I
wouldn't like anybody telling me he trusts my scripts or makefiles
and blindly runs them as root.
> (or maybe I trust that I can fix anything that can fsck up my system
> even with root perms ;))
I have an anecdote : several years ago, a collegue replaced me on a
benchmark platform during my hollidays. He wrote a few scripts to
help the guy doing the benchmarks, and one of his scripts archived
the logs and removed all the log directory and sub-directories to
prepare it for another run. When I came back, the guy doing the
benchs asked me to run this fresh new script to archive the logs,
which I tried. Unfortunately, it had to be run outside the log
directory so that it could find the directory name. One of its
lines was "rm -rf $LOGDIR/". Believe me, even on this Digital Unix
Alpha, it took a very long time to purge the directory when LOGDIR
was void, and we had to reinstall everything from scratch !
> I agree compiling the kernel as a non-root user is perfered but
> sometimes it doesn't happen that way...
Sudo generally helps here. It's even easy to put $SUDO in front
of sensible commands in build scripts and have SUDO=${SUDO-sudo}
at the beginning of the script.
Regards,
Willy
On Nov 27, 2005, at 05:57:00, Willy Tarreau wrote:
> On Sun, Nov 27, 2005 at 01:22:26AM -0800, David Brown wrote:
>> I agree compiling the kernel as a non-root user is perfered but
>> sometimes it doesn't happen that way...
>
> Sudo generally helps here. It's even easy to put $SUDO in front of
> sensible commands in build scripts and have SUDO=${SUDO-sudo} at
> the beginning of the script.
Even nicer: On Debian there's a "make-kpkg" command for building or
cross-compiling a kernel source tree and creating a debian package
from the result, and it can use "fakeroot" for all of the
intermediate steps. As a result, I can build a complete kernel
package with "make-kpkg --rootcmd=fakeroot [...]" as an ordinary
user, and then later install it as root with only one command: "dpkg -
i linux-image-2.6.15-rc2_2.6.15-rc2-1_powerpc.deb".
Cheers,
Kyle Moffett
On 11/27/05, David Brown <[email protected]> wrote:
> > It certainly is not an excuse, but at least it my explain why nobody
> > noticed it before you :-)
>
> Thanks for the info and suggestions ;)
> I trust Linus enough to compile a kernel as root... but maybe that's just me ;)
Well, Linus makes mistakes like everyone else. Besides, he himself
also recommends that people build kernels as non-root :
"I would suggest that people who compile new kernels should:
...
- compile the kernel in their own home directory, as their very own
selves. No need to be root to compile the kernel. You need to be root
to _install_ the kernel, but that's different. "
see http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html for the
source of that quote.
> (or maybe I trust that I can fix anything that can fsck up my system
> even with root perms ;))
>
> I agree compiling the kernel as a non-root user is perfered but
> sometimes it doesn't happen that way...
>
> - David Brown
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html