Hi Johannes,
Johannes Meixner [2008-04-08 10:02 -]:
> I like to learn which tool Ubunto uses to implement
> the "desktop-user" access.
We pretty much use the upstream solution now: ConsoleKit and
PolicyKit, and configuring hal with --enable-policy-kit
--enable-console-kit --enable-acl-managem
Till,
many thanks for the info!
Now it seems Ubuntu and Suse are in sync regarding the
defaults for user access which is certainly very good when
the end-user experience of different distros is very similar.
I like to learn which tool Ubunto uses to implement
the "desktop-user" access.
We use res
The access control for the non-printing functions of multi-function
devices (and also stand-alone scanners) was changed in Hardy. Now it is
not done any more via the "scanner" group, but the device files are now
always set to be accessible by the user who is currently logged in on
the desktop. So t
I should have mentionend that I had in mind to
run the backend as setuid "lp" program so that
normal users get sufficient permissions implicitely
e.g. to do a device state query.
I thought that "run as lp" is sufficiently secure because
"it is just what cupsd does by default" but unfortunately
I m
I really appreciate it that upstream accepts more secure
default permissions and we (i.e. Novell/Suse) have by default
rw-rw-r-- root lp
Unfortunately at least many of our users don't accept this
because only read access for normal usres is not sufficient
to query the device state from a printer (
Just a comment for Martin :)
The default hplip 2.7.9 tarball install sets the device node to "world-
writeable" only as a convenience to the user. We fully expect the down-
stream package maintainer or admin to change this user policy to any
other convention. Such as "scanner" or "lp" group member
Kees, the hpssd daemon is not packaged incorrectly. The "hplip" package
contains everything architecture-dependent, especially all binaries
compiled from C code. The "hplip-data" package contains everything
architecture-independent, especially all Python scripts. "hplip" depends
on "hplip-data", so
In the past (1.x in Feisty and Edgy) hplip started a "hplip"-user-run
daemon. In fact, it seems the gutsy hplip install still adds the user
for it. Additionally, the daemon in the 2.x version seems to be
incorrectly packaged into the hplip-data package instead of hplip
itself.
--
needs a proper
Bullet 1 in the initial posting is one problem, bullet 2 and 3 another
problem.
To fix bullet 1, a solution is to treat the device nodes like scanner or
sound device nodes: Permissions 0660, group ownership being a group
where only users who are allowed to use the desktop are members (esp. no
syst
mud i/o library> ah, thanks for the clarification.
--
needs a proper daemon or cupsys integration
https://bugs.launchpad.net/bugs/149045
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists
Disclaimer: I have no idea about hplip, Till and I have just discussed
that on IRC. However, bug 147369 seems to indicate that something in
hplip needs the devices world-writeable.
--
needs a proper daemon or cupsys integration
https://bugs.launchpad.net/bugs/149045
You received this bug notifica
This is a problem which can only be fixed upstream, so assigning to the
upstream developers at HP ...
** Changed in: hplip (Ubuntu)
Assignee: (unassigned) => David Suffield (david-suffield)
Status: New => Confirmed
--
needs a proper daemon or cupsys integration
https://bugs.launchpa
12 matches
Mail list logo
