Bug#389598: ITP: xpbiff -- animated mail monitor on X with popup notification
Package: wnpp Severity: wishlist Owner: Gernot Salzer <[EMAIL PROTECTED]> * Package name: xpbiff Version : 1.27-11 Upstream Author : Kazuhiko Shutoh, [EMAIL PROTECTED] * URL : http://www.logic.at/staff/salzer/xpbiff * License : Debian compatible Programming Lang: C Description : animated mail monitor on X with popup notification (Include the long description here.) xpbiff is a mail monitor like xbiff. It watches your mail file and informs you of new mail arrival using funny spinning mail animation. It can also popup the header line notification. MIME encoded Japanese Subject in JIS code can be shown well in that popup header. Copyright: * xpbiff - popup biff for X * * Author: Kazuhiko Shutoh, 1993 * * Permission to use, copy, modify and distribute without charge this software, * documentation, images, etc. is granted, provided that this comment and the * author's name is retained. The author assumes no responsibility for lost * sleep as a consequence of use of this software. * * Send any comments, bug reports, etc. to: [EMAIL PROTECTED] -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gdm/Gnome/KDE and device permissions
Dear DDs & D-friends,
what is the standard/canonical way of handling device permissions
in Debian ("etch" in my case) on desktop PCs running a GUI?
It seems that users have to be added to group "audio"
in order to be able to access audio devices, group "video" to access
video devices, "cdrom" to access cdrom, and so on. Or did I miss some
setting during installation of etch?
Having to add users to particular groups is not reasonable in a
desktop setting. There, one would like to have the current user
at the console (logged in via gdm or similar) to be the one with
exclusive rights on local devices (fixed ones like audio and video
as well as variable ones like external usb devices).
Part of the problem can be solved by using libpam-permdev:
it handles well fixed builtin devices like audio, video, cdrom,
but fails with dynamic devices like usb sticks (the pam module
is only active during login and therefore misses dynamic devices
plugged in during the session).
Moreover, since the module is not installed automatically with gdm,
it doesn't seem to be the intended solution.
For dynamic devices I haven't found a solution yet. Autodetection
and automounting of e.g. usb sticks works with gnome, if there are
entries in /etc/fstab. However, such entries are not reasonable
since one doesn't know in advance which devices are plugged in
in which order. I found some hints on the web how to use udev
hooks and events, but I suppose there are already ready-to-use
solutions somewhere hidden in Debian.
I'd appreciate any hints. Thanks in advance, and thanks for reading
this far,
Gernot
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
> > Having to add users to particular groups is not reasonable in a > > desktop setting. There, one would like to have the current user > > at the console (logged in via gdm or similar) to be the one with > > exclusive rights on local devices (fixed ones like audio and video > > as well as variable ones like external usb devices). > > I don't think it's possible to arrange for _exclusive_ access. Once a > user has been granted access to a group it is not really possible to > revoke the grant. Don't mechanisms like libpam_devperm grant exclusive access? On login the ownership of the devices is set to the console user, and only the owner is granted rwx-rights. On logout ownership/permissions of the device revert to the old setting. > There is also pam_group which seems to do the same thing--adds users to > groups depending on their name, login method and time of day. Thanks for the hint, I will check it. > Since groups are only set when a user logs in it's not possible to e.g., > add the user to the plugdev group when they plug in a USB stick. You'd > have to add them to plugdev when they log in. Couldn't a script triggered by udev set ownership/permissions to the current console user, like libpam_devperm does? > I think HAL/PolicyTool/pam_foreground will eventually give us a > (slow?) solution to problems like this, but it's some way off at the > moment. Being able to add/revoke permissions with traditional security > methods (i.e. group membership) requires kernel modification AFAIK. How do end-user Linux distributions that are supposed to work out of the box (like ubuntu, fedora, suse) solve this problem? World-rwx for all user devices? All users added to groups like "audio", "video", ...? Would it be possible to let all user devices (static or dynamic) be owned by group "console" with rwx rights, and add/remove the console user dynamically to/from this group on login/logout? This way it wouldn't matter whether e.g. the usb stick is plugged in before or after login. Wouldn't this solve the problem? Gernot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
> First, there is no safe way to revoke privileges from a user. If a user
> gets access to a certain group he/she can arrange ways to keep it,
> even after being logged out (make a suid binary for example).
I admit that I don't know much about the internals of Unix/Linux.
So, if upon login of user "foo" ownership/permissions of /dev/audio are set to
crw--- 1 foo audio 14, 4 2006-09-22 13:25 /dev/audio
and after logout of "foo" and login of "bar" to
crw--- 1 bar audio 14, 4 2006-09-22 13:25 /dev/audio
"foo" might still be able to access /dev/audio ?
> Second, several people can login at once on different VTs.
True, the general case is much more involved.
However, considering that the majority of desktops is single-headed,
it would be most useful to be able to install a package that sets up
the computer for this special case
such that people can work under gnome/kde like they are used to from
windows or mac-os. This includes to be able to access devices easily,
but without being pried upon by curious (but otherwise friendly and
non-hacker) remote users.
> Why would you want to bring udev in the picture? If you think the scheme
> used by pam_group (and similar) is secure enough for you, you can also grant
> access to the plugdev, netdev and powerdev groups.
I don't want to grant access to groups but rather want to mimic
the behaviour of libpam-permdev that changes ownership/permissions
of the device to grant only access to the console user.
Maybe "udev" is the wrong term; with udev I mean the part of the
system that creates devices dynamically and thus knows when and
at which device e.g. a usb stick was plugged in, and can initiate
the action of changing the ownership/permissions.
I found a partial solution somewhere on the web working like that.
> Note that access control
> is not hard coded to plugdev in dbus, you can edit the files in /etc/udev
> to have more relaxed access control. Oh, on debian you also need to change
> the permissions of p{u,}mount
> Afaik, fedora has pam_console or something like that does something like
> you suggest; give privileges to all users that log in at the console.
> Also dbus has some support for this, but this isn't compiled in the
> debian version, because of the caveats I outlined above.
Thanks, I'll check it.
> FWIW, there has been some discussion and ideas floating
> around on the HAL and DBus lists. The current consensus is that we need
> a secure way for dbus/hal to know what is the current active virtual
> terminal and how owns it. For mulit-head systems we need a way to
> specify that certain devices (think usb ports) belong to a certain
> display.
> Nobody has had time to implement it yet however.
Good to know. So I'm not wasting time when constructing a (simple) solution
for my situation.
Gernot
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Conflicting assignment of priviledged ports on boot
On boot some daemons (like nis/ypbind) obtain priviledged ports via portmap/bindresvport(). Portmap assigns ports that are not in use at the time of request, usually above 600. This strategy sometimes conflicts with daemons that rely on fixed ports and that start after ypbind (like cups, slapd): they find that their port is already in use. This problem is well known since at least two years, not just with Debian but also with other Linux versions like Redhat [1,2]. Starting ypbind later during boot is no solution in general since some services rely on ypbind AND fixed priviledged ports. Possible solutions are: - Modify portmap/bindresvport such that certain blacklisted ports are skipped even if they are not yet in use when a new priviledged port ist requested. - Make use of a program like portreserve/portrelease [3]. When the portreserve daemon is started, it examines the /etc/portreserve/ directory. Each file not containing "." or "~" in its name is considered to be a service configuration file, and must contain a service name (as listed in /etc/services) or a port number. For example, /etc/portreserve/cups might contain the string "ipp". For each service configuration file, a socket is created and bound to the appropriate port. A service wishing to bind to its port must first run portrelease, which instructs portreserve to release the port associated with the service. The second solution requires only a few changes to Debian: - every daemon relying on a fixed port that might be affected by portmap has to drop a file in /etc/portreserve upon package installation. Furthermore, its init script has to call portrelease before the daemon is started. - portreserve/portrelease has to be included with Debian. I propose to modify Debian in this way. Gernot [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103401 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306465 [3] http://cyberelk.net/tim/portreserve/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicting assignment of priviledged ports on boot
> why not request a fixed port for ypbind? It is not ypbind that is broken but the service that hands out the port numbers and that is called by ypbind (and by other services). It just happens that most clashes occur in connection with ypbind, due to its prominence and its place in the init sequence. And modifying a library routine seems to be not so easy, see Javier's post: > Portmap cannot be modified like that, as it only maps ports used by > applications, the applications themselves call bindresvport. > So this change actually means changing the libc which the libc maintainer > is against, and for good reasons (more rationale on RH's Buzgilla: #103401 > and #154800). Gernot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicting assignment of priviledged ports on boot
> FWIW, this bug has only been reported once (and reassigned to portmap) > see #261484 No. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306465 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257876 In each thread several people report of similar problems. > so its seems Debian users don't get beaten by this too often. It occurs (alomst) only during startup, and only if you run a service that starts early in the boot sequence and calls bindresvport (like ypbind) which is usually only the case with servers. I was bitten several times, but usually I just restarted a few services until it worked. Once the server ran there were no more problems. Bottomline: not every user is affected, but some are, and once they are affected, it is likely that the problem persists: the boot sequence is rather deterministic, so the clash will likely reoccur with every boot. > Yes, probably portreserve is the way to go. Although it might make sense to > coordinate this with other distros. Well, the problem has been around since at least 2002, so I'd prefer to start doing something about it. > In any case, this means changing > a number of packages (cupsys, IMAP/POP3 daemons, Ldap daemons) that > need to use RPC services and start _after_ those in the init sequence. > Maybe when somebody goes ahead and adds initscripts dependencies, as suggested > by Petter Reinholdtsen for LSB 3.0 compliance, we can have a good > understanding of what packages would need to be changed. The nice thing about portreserve/portrelease is that we don't need to have a good understanding. Modifying a package is safe: even if it starts long before nis nothing bad happens if the port is handled by portreserve. And if we miss to modify a package, we are no worse off than now. In fact, we are better off, because we will have an address where to send the bug report, namely to the package maintainer. Currently cups/ldap/... blames nis, and nis/... blames portmap, portmap blames glibc, and there are good reasons to leave glibc as it is. Gernot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conflicting assignment of priviledged ports on boot
> This was already brought up to debian-devel. This thread has more > solutions, but addresses less problems: what if the service is to be > started when the package is installed but a RPC programs already > listens there? The solution of shipping port reservations or of init > dependencies won't help for this problem. No, but it would help for most situations. With portreserve, the problem would occur _only_ when installing a new service, but not after reboots; moreover, it would occur only with _some_ installations, not always. And finally, the installation script can locate the error automatically (by checking whether the port is in use) and can suggest the installer a solution. This seems to be acceptable (even though this won't work with unsupervised installations). The situation would be much better than now, since one can be sure that once the service is installed, it will work in the future. > The only real option is to > change libc/portmap/all RPC services to consult a blacklist of ports > shipped in libc/portmap. Waiting for this solution means that probably nothing will change for the next few years, due to the side-effects of such a change. portreserve/portrelease, on the other hand, makes things only better, not worse; it does not interfere with the boot sequence as it is now, is easy to implement, and it does not interfere with an optimal solution where bindresvport takes care by itself. Thus portreserve can bridge the time until agreement has been reached about the optimal solution, and can be easily removed then. Waiting for all-or-nothing doesn't seem very attractive to me. Gernot
Conflicting assignment of priviledged ports on boot, once again
Hi, what is the collected wisdom nowadays on how to avoid random port conflicts when booting? In 2005 I wrote: "On boot some daemons (like nis/ypbind) obtain priviledged ports via portmap/bindresvport(). Portmap assigns ports that are not in use at the time of request, usually above 600. This strategy sometimes conflicts with daemons that rely on fixed ports and that start after ypbind (like cups, slapd): they find that their port is already in use." [http://lists.debian.org/debian-devel/2005/09/msg01062.html] (My description then was not accurate, since portmap only registers port bindings; but otherwise the issue remains.) I went on to suggest that Debian adopt the portreserve/portrelease approach [http://cyberelk.net/tim/software/portreserve/], which would solve many problems. In the ensuing discussion people acknowledged that there is a problem and that portreserve would help in most situations, but apparently it was not considered serious enough. In 2009, I'm still bitten by this problem, and it seems that not much has changed in Debian. Portreserve is available as package, but no service drops on installation the required info in /etc/portreserve . (It seems that Fedora in adopting this approach, though [https://fedoraproject.org/wiki/Features/Portreserve]). What is currently the expert way to avoid/handle such port conflicts in Debian? Thanks, Gernot -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conflicting assignment of privileged ports on boot, once again
> > What is currently the expert way to avoid/handle such port conflicts > > in Debian? > > /etc/bindresvport.blacklist Thanks for the hint, this is what I was looking for. So the world has moved since 2005, at list a bit. 873 (rsync) is not listed in this file. - Is this a "bug" in libc6? - ... or in rsync? (Are the services supposed to add their ports on installation?) - ... or is it up to the administrator to add the ports manually? I couldn't find any policy on who is responsible for entering the port number. It seems to be the last option, which is not completely satisfactory, since it involves trial-and-error. Gernot -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
