-rwsr-sr-x1 root root 7828 Apr 28 11:23 X
The 's' is a 'stickybit', right?
No.
,[ (coreutils)What information is listed ]
| The permissions listed are similar to symbolic mode specifications
| (*note Symbolic Modes::). But `ls' combines multiple bits into th
> Ron Graves <[EMAIL PROTECTED]> writes:
>
> > -rwsr-sr-x1 root root 7828 Apr 28 11:23 X
> > The 's' is a 'stickybit', right? Is this something Hurd needs?
No, it's the setuid and setgid bits. `t' would be the sticky bits.
On Mon, May 31, 2004 at 11:51:02AM -0700, Ron Graves wrote:
> On Monday 31 May 2004 12:40, Michael Banck wrote:
>
>
> > Do you (or anybody else) remember being asked this question during the
> > initial X install? If not, it might have a low debconf priority.
> >
> I don't remember being asked, b
On Monday 31 May 2004 12:40, Michael Banck wrote:
> Do you (or anybody else) remember being asked this question during the
> initial X install? If not, it might have a low debconf priority.
>
I don't remember being asked, but I set my question priority to 'medium.'
Ron
On Mon, May 31, 2004 at 11:11:52AM -0700, Ron Graves wrote:
> As for reconfigure xserver-common as 'anybody' it worked. I wonder
> why the 'Console Users Only' didn't? Thanks!
Good question. Perhaps something with PAM or so which we don't support?
I've no clue about this stuff.
Do you (or anyb
> The permission are identical on my GNU/Linux partition, btw:
Yes, I lied. Upon closer inspection the GNU/Linux was the same on mine too.
As for reconfigure xserver-common as 'anybody' it worked. I wonder why the
'Console Users Only' didn't? Thanks!
Any ideas on the /sbin/runlevel?
Ron
On Mon, May 31, 2004 at 11:28:24AM -0700, Ron Graves wrote:
> -rwsr-sr-x1 root root 7828 Apr 28 11:23 X
> The 's' is a 'stickybit', right?
I think it's rather the suid bit. stickybit is 't', AFAIK.
The permission are identical on my GNU/Linux partition, btw:
-rwsr-sr-x1 roo
> Somebody reported success with 'dpkg-reconfigure xserver-common' and
> changing it to 'anybody'. Don't know about the security implications of
> this though.
I haven't tried that yet. So, I will do it now.
Ron
> More helpful would be to know what the errors are that you get when
> you run startx.
start of error quote:
X: user not authorized to run the X server, aborting.
giving up.
xinit: No such file or directory (errno 1073741826): unable to connect to X
server
xinit: No such process (errno 1073
Ron Graves <[EMAIL PROTECTED]> writes:
> > Still, why would you want to turn it off, since we may in the future
> > take it as some kind of VM preferencing hint?
>
> I can't 'startx' as an unprivileged user. Not knowing the purpose
> of 's', and comparing permissions of my working Debian GNU/Lin
On Mon, May 31, 2004 at 11:46:45AM -0700, Ron Graves wrote:
> However, it seems that every other aspect is properly set. I think I
> will just stop wasting time and settle on the console.
Somebody reported success with 'dpkg-reconfigure xserver-common' and
changing it to 'anybody'. Don't know abou
Ron Graves <[EMAIL PROTECTED]> writes:
> -rwsr-sr-x1 root root 7828 Apr 28 11:23 X
> The 's' is a 'stickybit', right? Is this something Hurd needs? Can I chmod
> +x X, without causing any grief.
Right now it's ignored, but we may well in the future have VM handling
pay attentio
> Still, why would you want to turn it off, since we may in the future
> take it as some kind of VM preferencing hint?
I can't 'startx' as an unprivileged user. Not knowing the purpose of 's', and
comparing permissions of my working Debian GNU/Linux setup lead to the
question. I gather the 's
-rwsr-sr-x1 root root 7828 Apr 28 11:23 X
The 's' is a 'stickybit', right? Is this something Hurd needs? Can I chmod
+x X, without causing any grief.
When updating / installing certain packages, I get an error involving
inetutils-inetd. One of the problems is that /sbin/runlev
14 matches
Mail list logo
