Linux-Development-Sys Digest #289, Volume #6 Sat, 16 Jan 99 08:14:00 EST
Contents:
Re: Open Configuration Storage - was Registry for Linux (George MacDonald)
Re: disheartened gnome developer ([EMAIL PROTECTED])
Re: 2.2.0pre7 problem with can't find map file (Bill)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: IPMasquerading / SSH (Peter Samuelson)
Re: disheartened gnome developer (Richard Kulisz)
Re: What's going on here? (Peter Samuelson)
Re: Resuming a program execution after SIGSEGV excep. (Peter Samuelson)
Re: Secuity hole with perl (suidperl) and nosuid mounts on Linux (Peter Samuelson)
----------------------------------------------------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: Fri, 15 Jan 1999 05:29:27 GMT
Christopher Browne wrote:
>
> On Thu, 14 Jan 1999 06:53:58 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
> >Christopher Browne wrote:
> >> But a tool that exported this into a form where it *looked* like a
> >> virtual file system (like /proc) would allow one to readily use existing
> >> file management tools to examine system configuration. And possibly
> >> even manipulate it, given the ability to write to the "virtual files."
> ...
> >> We 'win' if we can get a suitable representation that lets us use
> >> existing tools 'for free.'
>
> >Using /proc a lot myself, I rather like this idea. If I understand
> >correctly a loopback file system would allow the implementation
> >to be a program vs in the kernel.
>
> I think so. I have yet to make use of loopback for anything useful.
>
> Unfortunately, this provides a Linux-specific approach to this, and
> further, one which requires a particular kernel function, which makes me
> a little uneasy, from two perspectives:
>
Well it doesn't have to be the only way to view the information, i.e.
a opStoreGet, opStoreSet command could also be used in shell scripts to get/set
values. I was actually thinking it would just be a nice addition, in
much the same way that other parts of /proc are linux specific additions.
Probably better to tackle that issue if/when it comes into common
usage.
> a) It means that we have to "impose" a particular kernel configuration
> on users of this facility.
>
That's enough to kill it for general usage, unless we convince the
kernel guy's that it makes a good logical extension to /proc and
that it should be part of the kernel. We would have to prove our
metal first.
> b) It isn't friendly to other systems (FreeBSD, Hurd, other "official
> UNIXes") that might be able to use this sort of functionality.
>
One could do it NFS style and loopback to the current system, not
exacly the most efiicient way to do it. Also not so easy in the
above systems. Better just to say it's an optional feature.
> What The World Probably Needs is some common "loopback scheme" where the
> same "front end" code can be connected using a common interface to Linux
> and some of the BSDs.
>
Outside the project scope, but a good idea.
> Make sure that the common interface isn't dependent on things that users
> will have to fool with very much, so that it is *easy, easy, easy* to
> connect things to this "generic loopback" system, whether we're talking
> Linux 2.0.x, 2.1.x, 2.2.x, or FreeBSD [whatever] or OpenBSD [whatever].
> Given some reasonable population that uses the scheme, this can be
> enough to encourage its adoption elsewhere.
I could see different implementations, i.e. one in C++, one
in CORBA, one in C ... The key components being the file
format, the interface communication, a common protocol.
Language bindings would off course vary from language to language,
but should luke similar. As you said, "easy, easy easy" is the
mantra.
>
> >In my original plan I was thinking about combining the
> >"system config tree" with the "user config tree" to provide
> >a config tree. My initial thoughts were to use "helper processes".
> >These could be called "store managers", and thier purpose
> >would be to do the notification for config change listeners
> >as well as other things such as performance improvements.
> >
> >Your probably wondering about having a "user store" process.
> >I figured it would be better to also have a per user process vs just
> >one system daemon. Partially because of load distribution,
> >partially because of security issues(i.e. when writing a
> >file in user space the process needs to be setuid to
> >the appropriate user so the file ownership works). This is
> >similar to what sendmail does when processing mail for
> >a particular user.
>
> That sounds pretty sensible. If a *LOT* of messing around with
> configuration is taking place, it makes sense to have multiple processes
> around.
>
Well the user one is transient with user sessions and could also
be dynamically activated if needed. The system level process could
be spawned by inetd on demand, but as you say once these things
run they eventually page out if not used. They would most likely
be a small core with some demand loaded libs.
> - An extra couple processes that sit largely idle won't be costly;
> - If you reduce the likelihood that any process will become a
> bottleneck, that's also good.
>
> >The only problem I see with this idea is that the "object
> >names" would be limited to the normal file name space
> >limitations. Not a huge limitation.
>
> Workarounds should be possible.
If we are going to define a name space for objects that users
will sometimes view, then using the file system name space
restrictions are reasonable.
>
> >How did you envisage implementing it? As a kernel module
> >or a user space process? Would you still keep user
> >config settings under the users space i.e. $HOME?
> >I have several reasons for wanting to do it that way, a big
> >part is that a user can copy there $HOME and all
> >there settings get copied.
>
> User space, for sure.
>
> Having user-specific config sit in $HOME has the benefits you indicate,
> as well as the consideration that it can be NFS mounted to multiple
> systems.
Which means we should account for a "host specific" fork when needed.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 16 Jan 1999 01:12:24 -0800
In article <77phat$[EMAIL PROTECTED]>, Navindra says...
>
>
>Toolkit programming in C seems to be really ugly. (see code below)
>Why would people want to use C for that when it's so much cleaner in
>C++? (or maybe it's just Qt that's magic)
>
>> Well I can say many people are coding away in Gtk. (Which I should be
>> doing right now, instead of wasting my time in this thread.)
>
>In C?
>
is GTK API more suited for C++ while Qt for C?
offcourse OO is more powerfull !
(good examples!)
Bob
------------------------------
From: Bill <[EMAIL PROTECTED]>
Subject: Re: 2.2.0pre7 problem with can't find map file
Date: Fri, 15 Jan 1999 03:27:34 -0500
Frank Hale wrote:
>
> I have 2.2.0pre7 loaded on my RedHat 5.2 box and everything is good. I
> upgraded my modutils package to modutils-2.1.121.
>
> I get the following errors on boot
>
> Jan 15 00:29:16 FranksPC kernel: Cannot find map file.
> Jan 15 00:29:16 FranksPC kernel: Error seeking in /dev/kmem
> Jan 15 00:29:16 FranksPC kernel: Error adding kernel module table entry.
>
> But the system is fine. All my modules load. PPP works, I can dial up to
> my ISP, mount drives, use my sound card. No other error but that.
>
> I copied the System.map to the /boot directory after I compiled
> 2.2.0-pre7 and I created the symlink. But I can't get rid of that error.
>
> Anyone else have the same error messages?
>
Yes exactly the same error messages and after asking in an irc room and
posting to a couple of news groups got no real answer.
I've put map and system map everywhere i thought the kernel might look,
/ , /lib/modules/2.2.0pre1 and /boot and still get those messages.
If you find out whats causing it/an answer. Please let me know.
I'm using 2.2.0pre1
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Fri, 15 Jan 1999 08:50:53 GMT
Leslie Mikesell wrote:
>
> In article <[EMAIL PROTECTED]>,
> George MacDonald <[EMAIL PROTECTED]> wrote:
>
> >I find some end users who spend a considerable amount of time
> >customizing their software. Although these are fewer in number
> >to those I see who are just trying to accomplish some task.
>
> If you can generalize at all about this, you might say that
> end users only spend time customizing their software if it
> isn't 'good enough' by default.
Well mostly, I call those the "reactive" users. There are the
"proactive" users, but there are fewer of them.
>
> >> From the admin perspective I would prefer that
> >> machines just pick up their defaults automatically unless someone
> >> who knows what they are doing specifically sets them up for
> >> local overrides.
> >
> >So if the OS has an ethernet card, and detects it's on a lan it could
> >broadcast for "opStore" servers, then ask one or more of these for the
> >settings for this "kind" of machine.
>
> Broadcasting is a really evil thing to do and won't work if there
> are routers between you and the server. Better to issue an
> http or tftp request to some well known name in your domain and
> define some identifying token that should be in the response.
That assumes the system has been configured, wern't we talking
about a system that just had a "fresh" image installed?
If it's configured then sure do as you suggest, if you build
a custom image you can also do as you suggest. So you could
either setup for "known stores" or take a quick peek around
the neighborhood to see what's there. A few other options
also exist, stores could advertize and there could be a
"yellow pages" type service on your network.
>
> >I could see different users
> >or machine types getting different settings. I suppose some profile
> >information could be sent to the "opStore" server to help
> >it define what information to return.
>
> The scheme will probably need some kind of identification and/or
> authentication for some of the settings.
Yes, I was thinking about some kind of higher level service that
would load settings that are suited to the users hardware,
job function, ... Some really large organizations could organize
config info in class hierarchies then assign a new user a
predefined "role", which could trigger a set of config values.
i.e. all EE's get a laptop configured for the companies
design suite. EE's in the chip lab also get the synopsis
suite ...
>
> >> I think this suits the typical office/network
> >> end user as well, and the developer who knows enough to be
> >> dangerous can undo it to keep everyone happy. However, I had
> >> been thinking in terms of a new automatic servics for this.
> >> Perhaps it really maps into what an NT domain controller does
> >
> >Could you briefly explain it, I don't know NT.
>
> I'm not runnig a domain controller myself, but basically when you
> 'log in' to an NT domain your client machine sends you login name
> and password to the controller, then executes a start-up script
> from there that is supplied by the administrator - this can
> link up drives, printers, etc. Samba is supposed to emulate
> most of the functionality of a domain controller now. I don't
> know where the client side stands in terms of being able to pick
> up a file from the controller.
>
> >Well it would be nice to make that an option, however many
> >users will not even have samba on their systems. I think
> >what we are talking about could do what you describe,
> >but it would not be "hard coded" that way. In some ways
> >what you describe is like diskful clients that mount
> >$HOME from a network server, i.e. the NFS senario. And
> >then perhaps mount local space into the remotely mounted
> >$HOME. Hmm, yet another senario. Anyhow these are some
> >of the existing techinques that solve part of the
> >problem. NDS looks like the system that addresses more
> >of the "network" problem than any others I have seen so far.
>
> The problem is common enough that a lot of solutions have been
> tried. The net effect is that the adminstator has to do
> everything a dozen different ways or limit the kinds of OS's
> that he supports. Or a company needs different administrators
> for each networking protocol. I'd hate to see Linux add yet
> another to the mess without solving anything new. There has
> to be some way to 'discover' resources that uses one of the
> existing protocols.
>
You describe a problem I consider outside the scope of opStore,
but that could be integrated into opStore if/when implemented.
In otherwords if there is a NT controller running as you say,
then the samba implementation running on a Linux client allows
end users to make use of the services offered via samba.
If there is configuration information available via this mechanism
then yes it could be supported via an opStore backend module.
In Unix/Linux the printers are configured by root, so that part
would be handled by a "systemStore" vs. a "userStore". Well
I suppose the userStore could refer to printers objects in
the systemStore and users might define default printers
and settings for particular contexts and overrides for
applications ...
Perhaps the way to handle this would be with a resource
assistant that finds network resources and creates dynamic
objects in the systemStore. These could then be discovered
via the normal opStore API. Perhaps the printer objects could
be persistent but have meta data(objects) that describe it's
current service level(available/not/...).
> >Thier solution is a bit more network centric, I was thinking more
> >of a model in which the network connections may/may not
> >be there and may come and go(i.e. portables roaming).
>
> Does the coda filesystem do anything that might be useful here?
Yes it can store config info, hence a module could be written
to use it. Requiring Coda would not fly, the people who invented
it are the ones working on ACAP.
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: IPMasquerading / SSH
Date: 16 Jan 1999 04:55:04 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Daniel R. Grayson <[EMAIL PROTECTED]>]
> > > on host B, the command "netstat -M" will display each such
> > > "masqueraded" connection, together with its expiration
> > > time. I can watch the time till expiration tick down
> > > from 15 minutes to 0 for the connection from A to C --
> > > each time some data are exchanged, it gets reset to
> > > 15 minutes. Eventually the connection is terminated.
[Me]
> > The burning question is -- are you absolutely sure it's not host C
> > which is doing the disconnecting? That's what Mark was getting at.
[Daniel Grayson]
> Oh. Well, sure, before we started using masquerading, we could stay
> connected while idle.
>
> Isn't it convincing that host B above has a visible expiration time
> ticking down to 0, at which time the connection is broken?
Quite convincing. Sorry, I misunderstood the part where you explained
all that the first time around.
(I don't know what I'm doing in this thread anyway. I don't use masq
and never have, so most probably I can't help you.)
Of course, if you can't find a solution to your timeouts, you may wish
to kludge some sort of keepalives. For example, if the remote system
supports writing to /dev/tty in the background, you could have a
process send a no-op control sequence to /dev/tty every ten minutes if
~/.bash_profile somehow detects that you're coming in over a masq
line....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Richard Kulisz)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 16 Jan 1999 10:46:05 GMT
In article <77h02n$bg6$[EMAIL PROTECTED]>,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>None of those things represent "communism."
Oh, but they do.
>Communism has to do with doing things specifically for "the common
>good."
>
>If I *enjoy* playing a sport, playing music, singing, or whatever, my
>engaging in such activities is not "communistic." I do these sorts of
>things because *I find it beneficial.*
What you feel or do not feel is entirely irrelevant since other people
do not have access to your feelings, and those other people matter a
whole lot more than you do. From their point of view, the only important
thing is that you *do* in fact accomplish something that benefits the
whole community far *far* more than it benefits you. Then it's communism.
Motivation is irrelevant, only the objective actions of the system are
relevant. A system can be communistic just as easily by bribing everyone
into doing what is good for the community as by educating everyone into
doing the right thing.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: What's going on here?
Date: 16 Jan 1999 05:20:16 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Dr. Unk <[EMAIL PROTECTED]>]
> What's the deal here? 2.0.36 in the Stable corner, 2.1.132 in the
> Development corner. Now 2.2.0 in the Development corner. Supposedly
> the even number after the 1st number means it's stable. Does this
> mean that 2.2.0 is stable, or will it be the new stable after a
> million patches?
You're almost right. The patchlevel (the second digit) is odd for
"development" kernels and even for "stable" kernels, so 2.2.x will be
considered the new stable series.
However, 2.2.0 has NOT been released yet. The latest version as of
this writing is 2.2.0pre7, which could be considered the seventh beta
release. As a beta, it is still considered "development". For an
unofficial list of what is considered beta about it, read
http://roadrunner.swansea.linux.org.uk/jobs.shtml . 2.2.0 will be
released when Linus is satisfied that most or all of the showstopper
bugs have been dealt with.
Actually, when 2.2.0 comes out, there will be two stable releases.
Alan Cox has stated that at least for awhile he will continue to
maintain the 2.0.x branch, so that people who do not want to be forced
to upgrade to 2.2.x right away can still get important bugs fixed.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Resuming a program execution after SIGSEGV excep.
Date: 16 Jan 1999 05:26:05 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Bjorn Reese <[EMAIL PROTECTED]>]
> > This can usually be done within the signal handler, if you only
> rely on MT-Safe functions. You can
> ^^^^^^^
> Whoops, I meant to say Async-Safe.
I'm not a threads guy. So, out of curiosity, what is async-safe? Is
it anything like reentrant? (I think I understand the difference
between mt-safe and reentrant -- has to do with deadlocking, yes?)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.misc,comp.lang.perl.misc
Subject: Re: Secuity hole with perl (suidperl) and nosuid mounts on Linux
Date: 16 Jan 1999 06:11:25 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Brian McCauley <[EMAIL PROTECTED]>]
> The suid script emulation in Perl 5.0004_4 (as found in SuSE Linux
> 5.3 and doubtless other Linux distributions) fails to take account of
> the nosuid mount option on filesystems.
Ah, but have you actually tried to exploit this? It won't work. The
kernel tests for this (check the source at fs/exec.c:550-562 in 2.0.35
or fs/exec.c:647-661 in 2.2.0pre7). It'll just return EPERM
("Operation not permitted") to the execve() call. Doesn't matter if
you're talking about suidperl or the real thing -- if the file is
marked setuid or setgid it simply won't run (unless you are root, or
you already have the same UID/GID as the file).
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
